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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines optional Optimal Media Routeing (OMR) procedures that can be applied by entities in 
the IP Multimedia Subsystem (IMS) that control media resources and are capable of manipulating the Session 
Description Protocol (SDP) as defined by IETF RFC 4566 [6]. 

The OMR procedures in the present specification relate to the handling of OMR-specific SDP attributes that are 
documented in TS 24.229 [4]. The OMR procedures use SDP offer/answer related procedures in IETF RFC 3264 [5] 
and in 3GPP TS 24.229 [4] in a backward-compatible manner. 

The 3GPP network architecture, including the configuration and network entities of the IMS, is defined in 3GPP TS 
23.002 [2]. The stage 2 of the IMS is defined 3GPP TS 23.228 [3]. Annex Q of 3GPP TS 23.228 [3] documents the 
architecture and call flows for OMR. 

The OMR procedures in this document are applicable to the following IMS entities that perform as an IMS-ALG or UA 
according to 3GPP TS 24.229 [4] and that control media resources: 

- an IBCF acting as an IMS-ALG; 

- a P-CSCF acting as IMS-ALG; 

an AS acting as B2BUA and adapting IMS-ALG procedures to control an MRF; 

an AS acting as B2BUA and adapting UA procedures to control an MRF; and 

- an MGCF acting as UA. 

NOTE 1 : An AS acting as B2BUA to perform application functions such as conferencing or announcements will 
normally perform separate originating and terminating UA procedures, treating the media resource as an 
endpoint. An AS acting as B2BUA offering transcoding options will typically follow IMS-ALG 
procedures. 

NOTE 2: The controlled media resource can be a TrGW, IMS-AGW, MRF, or a media function of the entity 
performing OMR. 

The OMR procedures are not applicable for an UE. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1], and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

Codec: A media configuration for a media line in SDP that is specified by one or more formats in the format list of the 
m-line, by one or more preferred configurations (pcfg) associated with the media line, or by a combination of both. 

Codec Change: Any modification to the media configurations for the media line in the format list or the list of 
preferred configurations. 

Codec List: Either the format list of the m-line, or a combination of all the preferred configurations and the format list 
for the media line. 

Connected IP realm: Compared to a reference IP realm, a connected IP realm is one identified with a different unique 
name where all IP endpoints in the two IP realms are mutually reachable (accessible) by means of IP routeing without 
address translation. Interconnection between the IP realms may be via direct link, via IP tunnel through other networks, 
via IP routeing through intermediate networks, or via any other method of internetworking as long as their IP endpoints 
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are mutually reachable. The property of connectedness is symmetric but not necessarily transitive. In particular, two IP 
realms connected to a reference IP realm are not necessarily themselves connected. 

Incoming termination: The termination at an MR in the direction from where an incoming SDP offer is being received 
at the IMS-ALG that is controlling the MR. 

IP realm: A collection of IP endpoints identified by a unique name, where all IP endpoints are mutually reachable by 
means of IP routeing without address translation. 

Media resource: An IMS Network entity that provides resources to process media streams and is controlled by an 
entity applying OMR procedures. A TrGW, BGW, MRF, or a function internal to the entity performing OMR can be a 
media resource. 

Loopback routeing: A method of routeing a SIP request back to the visited network for local breakout according to the 
Roaming Architecture for Voice over IMS with Local Breakout as specified in 3GPP TS 24.229 [4]. 

Outgoing termination: The termination at an MR in the direction towards where an outgoing SDP offer is being sent 
at the IMS-ALG that is controlhng the MR. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Ix Reference Point between IBCF and TrGW 

Iq Reference Point between the P-CSCF and the IMS Access Gateway 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 2L905 [1], in 3GPP TS 23.228 [3] and 
the following apply. An abbreviation defined in the present document takes precedence over the definition of the same 
abbreviation, if any, in 3GPP TR 2L905 [1] or in 3GPP TS 23.228 [3]. 

ALG Application Level Gateway 

B2BUA Back-to-Back User Agent 

IC Interconnection 

ICE Interactive Connectivity Establishment 

MR Media Resource 

OMR Optimal Media Routeing 

TRF Transit and Roaming Function 

UA User Agent 



General 



The procedures in clause 5, clause 6 and clause 7 shall apply separately to each media line with non-zero port value in 
each SDP message, and shall apply separately to each SDP offer/answer transaction. In the presence of forking of a SIP 
INVITE request that includes an SDP offer, the OMR procedures for handling of the SDP offer apply once for all 
forked dialogs, and the OMR procedures for handling of the corresponding SDP answer apply independently to each 
dialog. Entities supporting OMR use the OMR-specific SDP extension attributes defined in 3GPP TS 24.229 [4]. 

OMR builds on the ALG NAT traversal model and is not consistent with ICE. 

OMR does not modify the SIP signalling route path and usually does not modify the flow of SIP messages except in 
some cases when transcoding options are offered. 
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Common SDP Procedures 



5.1 General 

The IMS-ALG or UA using the OMR procedures in clause 6 or clause 7, respectively, shall additionally use the 
procedures in this subclause when manipulating SDP. 

5.2 Encapsulation of previous SDP information 

5.2.1 Media level information 

If an IMS-ALG forwards an SDP offer and for a given media line: 

adds or removes offered format(s); 

modifies the transport protocol; 

adds or removes other corresponding media level SDP attribute(s) than "visited-realm", "secondary-realm", "omr- 
codecs", "omr-m-att", "omr-s-att", "omr-m-bw", "omr-s-bw", "omr-s-cksum" or "omr-m-cksum" attributes; 

modifies the value of other corresponding media level SDP attribute(s) than "visited-realm", "secondary-realm", 
"omr-codecs", "omr-m-att", "omr-s-att", "omr-m-bw", "omr-s-bw", "omr-s-cksum" or "omr-m-cksum" attributes; 

adds or removes corresponding media level SDP bandwidth line(s); or 

modifies the value of corresponding media level SDP bandwidth line(s), 

then the IMS-ALG shall apply the procedures below to encapsulate all media level information of the corresponding 
media line. 

The IMS ALG shall encapsulate the received transport protocol and format list of the corresponding media line within 
an "omr-codecs" attribute and add this attribute as a media level attribute for the corresponding media line. 

The IMS ALG shall encapsulate each received attribute of the corresponding media line within an "omr-m-att" attribute 
and add this attribute as a media level attribute for the corresponding media line. 

The IMS ALG shall encapsulate each received bandwidth line of the corresponding media line within an "omr-m-bw" 
attribute and add this attribute as media level attribute for the corresponding media line. 

If the IMS-ALG received any visited-realm instances in the SDP offer, the IMS-ALG shall supply the instance number 
one above the highest instance number in the received SDP offer as instance number within the "omr-codecs", the "omr- 
m-att" and "omr-m-bw" attribute(s). Otherwise the IMS-ALG shall supply the instance number 2. 

5.2.2 Session level information 

If an IMS-ALG forwards an SDP offer and: 

encapsulated any media level information according to the conditions in subclause 5.2.1; 

adds or removes any session level SDP attribute(s); 

modifies the value of any session level SDP attribute(s); 

adds or removes session level SDP bandwidth line(s); or 

modifies the value of session level SDP bandwidth line(s), 

then the IMS-ALG shall apply the procedures below to encapsulate all session level information. 

The IMS ALG shall encapsulate each received session-level attribute within an "omr-s-att" attribute and add this 
attribute as a media level attribute for every media line. 
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The IMS ALG shall encapsulate each received session-level bandwidth line within an "omr-s-bw" attribute and add this 
attribute as a media level attribute for every media line. 

If the IMS-ALG received any visited-realm instances in the SDP offer, the IMS-ALG shall supply the instance number 
one above the highest instance number in the received SDP offer as instance number within the "omr-s-att" and "omr-s- 
bw" attribute(s). Otherwise the IMS-ALG shall supply the instance number 2. 

NOTE 1: The instance number 1 is reserved for the incoming SDP offer when it contains no visited-realm instance. 

NOTE 2: The remaining SDP session level attributes (e.g., the "o" line) are not modified by the OMR procedures. 

5.3 Determination of codec related SDP information associated 
to a previous realm instance 

When deciding to bypass some previous MR, an IMS-ALG needs to determine the SDP information which is applicable 
together with the visited-realm instance or secondary-realm instance that the IMS selects for the bypass (see subclause 
6.1). The IMS-ALG will include that SDP information in a forwarded SDP offer or perform additional modifications on 
top of it, e.g., to offer transcoding at its own MR. 

To determine the codec related SDP information associated to that previous realm instance for the media line, the IMS- 
ALG shall use the procedures below. 

1) If any "omr-codecs", "omr-m-att", or "omr-m-bw" attributes with a higher instance number than the previous 
visited-realm instance or secondary-realm instance exist for a media line, the IMS-ALG shall consider the 
information within the set of attributes with the lowest instance number among those as follows: 

the IMS-ALG shall replace the transport format and media formats in the media line with the transport 
format and media formats from the "omr-codecs" attribute with this instance number; 

the IMS-ALG shall retain all the "visited-realm", "secondary-realm", "omr-s-cksum", "omr-m-cksum", "omr- 
codecs", "omr-m-att", "omr-s-att", "omr-m-bw" and "omr-s-bw" attributes for the media line and replace all 
other SDP a-line(s) for the media line with the attributes extracted from the "omr-m-att" attribute(s) with this 
instance number; and 

NOTE 1 : This procedure only describes update to codec related SDP information. Clauses 6 and 7 describe the 
corresponding modifications to the OMR related attributes. 

the IMS-ALG shall replace the SDP b-line(s) for the media line with the b-line(s) extracted from the "omr-m- 
bw" attributes with this instance number. 

Otherwise, the IMS-ALG shall use the SDP a-lines, b-lines, transport format and list of media formats of the 
corresponding media line. 

2) If any "omr-s-att" or "omr-s-bw" attributes with a higher instance number than the previous visited-realm 
instance or secondary-realm instance exist, the IMS-ALG shall consider the information within the set of 
attributes with the lowest instance number among those as follows: 

If the same attributes are provided for each media line, the IMS ALG shall replace all session-level SDP a- 
lines and b-lines with the encapsulated attributes and bandwidth within the "omr-s-att" attributes and "omr-s- 
bw" attributes of one media line as session level attributes and bandwidth, and may apply attribute or 
bandwidth modifier specific logic to verify and possibly adjust the session-level information from "omr-s-att" 
and "omr-s-bw" attributes and media level information determined as described above; 

NOTE 2: Verification helps in the possible event of splitting media lines by intermediate entities. 

otherwise the IMS-ALG shall apply attribute or bandwidth modifier specific logic to derive appropriate 
session-level information from "omr-s-att" and "omr-s-bw" attributes and media level information 
determined as described above, or delete all those encapsulated attributes and all session-level SDP a-lines 
and b-lines. 

NOTE 3: In the possible event of merging of media lines by intermediate entities, there may be inconsistencies in 
the encapsulated session level a-lines and/or b-lines. 

3) Otherwise, the IMS-ALG shall use the session-level SDP a-lines and b-lines. 
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For an SDP offer with several media lines, an IMS-ALG applies the OMR algorithm separately for each media line and 
can select different optimised paths. In such a case, the session-level attributes and bandwidth information determined 
by the above algorithm can differ for different optimised paths, depending on the selected visited-realm instance or 
secondary-realm instance for each media line. The IMS-ALG may then apply attribute or bandwidth modifier specific 
logic to determine the appropriate session-level information or discard conflicting information. An IMS-ALG may also 
apply a policy not to choose different optimised paths for different media to avoid such conflicts. 

NOTE 4: Upon receiving an SDP offer and validating the OMR attributes in the SDP offer, but before making any 
codec changes to the SDP offer, the IMS-ALG supporting OMR can delete any unsupported attributes 
from the SDP offer, e.g., attributes associated with capability negotiation. The IMS-ALG supporting 
OMR can also delete any ignored attributes, e.g., due to lack of support of a required extension to 
capability negotiation, as determined by the creq attribute defined in IETF RFC 5939 [20]. 

5.4 Modifying codec related information 

5.4.1 IVIodifying the format list 

When forwarding an SDP offer, the IMS-ALG should not make changes to the attributes associated with a format 
remaining in the format list of the m-line that require the allocation of an MR to translate the media payload between 
the format described by the received SDP offer and the format described by the forwarded SDP offer. 

NOTE 1 : Examples include changing between AMR octet-aligned and bandwidth-efficient modes, and 
incompatible AMR mode-sets. 

To add a codec to the format list of the m-line in the SDP offer to be forwarded, the IMS-ALG shall either: 

add a media format to the format list on the media line that is different from any format in the "omr-codecs" 
attributes for the media line, along with any necessary media attributes, or 

re-insert a format from an "omr-codecs" attribute for the media line that is not in the current format list, along 
with the corresponding attributes for the format with the same instance number in "omr-m-att" attributes. 

NOTE 2: This procedure avoids the potential need to retain a media resource to perform format mapping when 
performing proactive transcoding, if the bypass decision is based on the SDP answer. 

5.4.2 IVIodifying preferred configurations 

When forwarding an SDP offer, the IMS-ALG supporting SDP capability negotiation shall only make a change to a 
preferred configuration in the incoming SDP offer without changing the configuration number if the change is 
backward compatible. A backward compatible change is one that, if it is selected as the actual configuration, does not 
require the allocation of an MR to translate the media payload between the format described by the received SDP offer 
and the format described by the forwarded SDP offer, and does not require modification of the actual configuration 
number when forwarding the SDP answer. This applies to the preferred configuration (pcfg) itself and any capabilities 
referenced in the pcfg. 

NOTE 1: It is recommended that an IMS-ALG not make any codec list changes to an SDP offer that includes any 
mandatory session capabilities unless it also deletes all attributes associated with capability negotiation as 
if capability negotiation were not supported. 

To make any of the following changes to a preferred configuration in the SDP offer: 

to change the priority of the preferred configuration with respect to others; 

to allow insertion of a new preferred configurations with higher priority; 

to allow reassignment of another preferred configuration to a higher priority; or 

to make any other changes to a preferred configuration that are not backward compatible and cannot be realized 
by inserting a new preferred configuration, 

the IMS-ALG shall reassign the configuration number to one unused in the SDP offer or in any of the encapsulated 
information for the media line in the SDP offer and add any necessary capability attributes. 
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NOTE 2: Changing the priority of a codec or preferred configuration increases the possibility of introducing a 

transcoding function that is not otherwise needed. Normally new or changed preferred configurations are 
assigned with higher configuration numbers (of lower priority) than existing preferred configurations. 

When forwarding an SDP offer, the IMS-ALG supporting SDP capability negotiation shall not change any existing SDP 
capneg capability attributes, but may insert additional capability attributes. 

The IMS-ALG may delete a preferred configuration from the SDP offer. However, the IMS-ALG shall not delete any 
unreferenced capability attributes. 

If the IMS-ALG desires to add a preferred configuration, it should search for an equivalent or backward compatible 
preferred configuration within the encapsulated codec related information. If it finds such a suitable preferred 
configuration, the IMS-ALG should reuse the configuration number from the encapsulated preferred configuration if the 
resulting priority with respect to other preferred configurations is acceptable. 

To add a new preferred configuration to the media line of the SDP offer that is different from and not backward 
compatible with any pcfg attribute in encapsulated codec information for the media line, the IMS-ALG shall allocate a 
new configuration number for the new preferred configuration with a configuration number unused by any other 
preferred configuration within the SDP offer or within the encapsulated codec related information. 

5.5 Additional handling for SDP answer with actual 
configuration 

In subclause 6.2.2 and subclause 6.2.8 step 4), if the media line in the SDP answer includes an actual configuration, the 
IMS-ALG should perform the following procedure to determine if the codecs in the SDP answer are supported by a 
previous version of the received SDP offer: 

The IMS-ALG should compare the actual configuration with SDP capneg preferred configurations in encapsulated 
codec related information to determine if previous realm instances are associated with matching codec related 
information. The actual configuration matches a preferred configuration: 

if the preferred configuration has the same configuration number as the actual configuration; or 

if the capabilities listed in the actual configuration match the capabilities available in the preferred 
configuration in the SDP offer. 

NOTE: An IMS-ALG can choose not to compare the SDP capneg actual configuration with encapsulated 

preferred configurations, or only to compare configuration numbers, but this may lead to a failure to find 
opportunities to bypass previous realm instances. However, SDP capneg procedures recommend that the 
offerer performs a second offer-answer exchange where the actual configuration is offered in normal 
SDP. Missed opportunities to bypass previous realm instances could still be found during this second 
offer-answer exchange. 

If the IMS-ALG selected a preferred configuration with a different configuration number than the actual configuration 
for bypassing a previous realm, the IMS-ALG shall change the capability number of the actual configuration to equal 
the capability number of the matching preferred configuration before forwarding the SDP answer. 

5.6 Procedures specific to OIVIR attributes 

5.6.1 General 

This subclause describes additional procedures specific to SDP attributes associated with OMR specified in 3GPP TS 

24.229 [5]. 

5.6.2 instance-number 

When creating a new visited-realm instance for a media line in an SDP offer, the IMS-ALG shall assign an instance- 
number value for the instance that is " 1 " higher than the highest existing instance-number value for any visited-realm 
attribute for any media line in the received SDP offer, starting with the value "1" if there are no such attributes in the 
SDP offer. If IMS-ALG adds visited-realm instances for several media lines, it shall use the same instance-number. 
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A UA creating a vi sited-realm instance for a media line in an SDP offer shall assign an instance-number value " 1 " for 
the instance. 

5.6.3 Session and media cinecksum calculation 

An IMS ALG or UA supporting OMR shall determine a session level checksum and a media level checksum for each 
media line containing a visited-realm SDP attribute. 

The session level checksum shall be calculated by summing all the hex values of the individual ASCII characters 
(excluding all white space) of the "b" and "a" session level lines. The media level checksum shall be calculated by 
summing all the hex values of the individual ASCII characters (excluding all white space) of the "m", "b", and "a" 
media level lines including attributes specific to OMR but excluding the session and media level checksum attribute 
lines themselves. 

When there are no "b" or "a" session level lines to calculate the session level checksum, the session level checksum is 
set to "0". 

5.7 Roaming architecture for voice over IIVIS with local breakout 

In a network supporting the roaming architecture for voice over IMS with local breakout OMR related policies may 
depend on the identification of a roaming architecture for voice over IMS with local breakout session. 

An IBCF acting as an IMS-ALG can identify a session to be a roaming architecture for voice over IMS with local 
breakout session as specified in 3GPP TS 24.229 [5], subclause 5.10.9. 



6 IMS-ALG procedures 

6.1 IMS-ALG handling of SDP offer 



6.1.1 General 

Upon receiving an SDP offer, the IMS-ALG supporting OMR shall apply the procedures in the following subclauses for 
each media line with non-zero port value. 

6.1 .2 Validating the received SDP offer 

If any of the following conditions are true: 

1) the received SDP offer includes any OMR attributes for the media line, but no visited-realm instance; 

2) the connection-address and port information in the visited-realm instance with the highest value of instance- 
number for the media line does not match the connection address and port information for the media line; or 

3) one of the following conditions are true: 

the "omr-m-cksum" attribute does not match the checksum value computed for the media line as described in 
subclause 5.6.3; or 

based on local policy, if the "omr-m-cksum" attribute matches the computed media line checksum, but the 
"omr-s-cksum" attribute does not match the checksum value computed for the session level lines as described 
in subclause 5.6.3, 

then the IMS-ALG shall remove all OMR attributes associated with the media line from the received SDP offer and use 
the modified SDP offer as the received SDP offer in the procedures in the following subclauses. 
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6.1 .3 Deciding winetlner to allocate a primary local MR and if any previous 
MR can be bypassed 

The IMS-ALG considers information in the received SDP offer and applies local policy to decide whether to allocate a 
primary local MR and if it is to bypass any previous MRs. 

NOTE: An IMS-ALG can revise these decisions when receiving the SDP answer, applying procedures in 
subclause 6.2. 

The IMS ALG shall perform the following steps: 

0) If the connection address for the media line in the received SDP offer is the unspecified address, then the IMS- 
ALG should: 

a) select to not allocate a primary local MR (regardless of local policy), and to not bypass any previous MRs; 

b) convert the unspecified address in the connection address for the media line in the received SDP offer to the 
addrtype of the outgoing IP realm, if necessary; 

c) if subsequently choosing to perform proactive transcoding in subclause 6.1.7, then select to perform 
proactive transcoding without resource reservation (regardless of local policy); 

d) select to not add secondary-realm instances to the modified SDP offer when performing the procedure in 
subclause 6.1.8 (regardless of local policy); and 

e) skip to step 6), 

1) If all of the following conditions apply: 

a) local policy does not require the allocation of an MR for any non-OMR related reason (e.g. for hosted NAPT 
traversal on the incoming signalling path, or for legal interception; and 

b) the IP realm, nettype and addrtype for the outgoing signalling path is the same as the IP realm, nettype and 
addrtype associated with a visited-realm or secondary-realm instance for the media line 

such that the instance has an instance-number value / that is less than the highest instance-number value n 
associated with the media line in the received SDP offer; and 

such that the instance / is associated with a codec list, determined using the procedures in clause 5.3, 
which includes all codecs required by local policy, unless the IMS-ALG has a policy to offer the missing 
codecs proactively without reserving an MR, 

then the IMS-ALG shall store an indication that the allocation of a primary local MR is not required and shall 
store the realm instances with instance-number greater than /, which are associated with MRs that can be 
bypassed without allocating a primary local MR. 

2) If the following condition applies: 

a) the IMS-ALG controls an MR with access to an IP realm or connected IP realm, nettype and addrtype 
associated with a visited-realm or secondary-realm instance for the media line 

such that the instance has an instance-number value j that is less than the highest instance-number value n 
associated with the media line in the received SDP offer; and 

such that the instance j is associated with a codec list, determined using the procedures in clause 5.3, 
which includes all codecs required by local policy, unless such codecs are provided at a local MR via 
transcoding, 

then the IMS-ALG shall store the realm instances with instance-number greater thany, which are associated 
with MRs that can be bypassed when allocating a primary local MR. 

3) If all of the following conditions apply: 

a) the condition in step 1) does not apply; 
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b) the IP realm, nettype and addrtype for the outgoing signalling path is the same as the IP realm, nettype and 
addrtype for the incoming signalling path; 

c) the codec list in the received SDP offer, determined from the SDP m-line and associated non-OMR attribute 
lines, includes all codecs required by local policy, unless the IMS-ALG has a policy to offer the missing 
codecs proactively without reserving an MR; and 

d) local policy does not require the allocation of an MR for any non-OMR related reason (e.g. for hosted NAPT 
traversal on the incoming signalling path, or for legal interception), 

then the IMS-ALG shall store an indication that the allocation of a primary local MR is not required and that no 
MRs can be bypassed when no primary local MR is allocated. 

4) If an indication that the allocation of a primary local MR is not required has been stored in steps 1) or 3), 

then the IMS-ALG shall compare the realm instances (and MRs) that can be bypassed with or without 
allocation of a primary local MR, as determined in steps 1), 2) and 3), and shall use local policy to select 
whether to allocate a primary local MR, 

else the IMS-ALG shall select to allocate a primary local MR, 

NOTE: Usually the decision is made based on which choice retains the smallest total number of MRs in the 
media path, but local policy may apply other criteria. 

5) If the IMS-ALG selected in step 4) to allocate a primary local MR, then the IMS-ALG shall: 

if one or more realm instances can be bypassed when allocating a primary local MR, then store instance- 
number value k=j and apply the procedures in subclause 6.L4 to bypass previous MRs, else apply the 
procedures in subclause 6.L5 to not bypass previous MRs; and 

apply the procedures in subclause 6.L6 to allocate a primary local MR. 

6) If the IMS-ALG selected in step 4) to not allocate a primary local MR, then the IMS-ALG shall: 

if one or more realm instances can be bypassed when not allocating a primary local MR, then store instance- 
number value k=i and apply the procedures in subclause 6.L4 to bypass previous MRs, else apply the 
procedures in subclause 6.L5 to not bypass previous MRs; and 

apply the procedures in subclause 6. 1 .7 to not allocate a primary local MR. 



6.1 .4 Bypassing previous MRs 



If the IMS-ALG decides (applying the criteria in subclauses 6.L3, 6.2.2, 6.2.3 or 6.2.8) to bypass a previous MR, the 
IMS-ALG shall: 

1) use the connection address and port information from the selected instance k for the media line in the received 
SDP offer as incoming connection address and incoming port information for the media line in the subsequent 
steps; 

2) reconstruct the associated codec information for the media line in the received SDP offer from the selected 
instance k as described in subclause 5.3, and use that codec information as incoming codec information in the 
subsequent steps; and 

3) delete every OMR attribute for the media line with instance-number value higher than k. 



6.1 .5 Bypassing no previous MRs 



If the IMS-ALG decides (applying the criteria in subclauses 6.L3, 6.2.2 or 6.2.3) not to bypass any previous MR, the 
IMS-ALG shall: 

1) use the connection-address from the SDP c-line in the received SDP offer as incoming connection-address in 
subsequent steps; 

2) use the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; and 
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3) use the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps. 

6.1 .6 Allocating a primary local MR 

If the IMS-ALG decides (applying the criteria in subclauses 6.1.3 or 6.2.3) to allocate a local MR, the IMS-ALG shall: 

1) if no MR context has been allocated due to a previous SDP offer-answer exchange, allocate an MR context with 
access to the IP realms, nettypes and addrtypes associated with the incoming connection address and port 
information determined in subclause 6.1.4 or 6.1.5, and the outgoing signalling path, respectively applying 
procedures as described in subclause 6.3; 

2) if the IMS-ALG is not performing hosted NAPT traversal on the incoming side, then insert the incoming 
connection address and incoming port information for the media line, as determined in subclause 6.1.4 or 6.1.5, 
into the remote connection address and port information for the incoming termination on the MR; 

3) if the IMS-ALG is performing hosted NAPT traversal on the incoming side, then discover the remote connection 
address and port information for the incoming termination on the MR using latching or other unspecified 
technique; 

4) if codec information is to be provided to the allocated MR on the incoming termination, provide to the MR the 
incoming codec information as determined in subclause 6.1.4 or 6.1.5; 

NOTE: The IMS-ALG can defer the allocation of an MR termination at the incoming side and the related 
procedures in steps 1) to 4) until it processes the SDP answer. 

5) if the IMS-ALG requires according to local policy that its MR remain in the media path for reasons unrelated to 
OMR, remove all OMR specific attributes from the modified SDP offer; 

6) if there is no visited-realm instance associated with the connection address and port information for the media 
line in the received (and possibly modified) SDP offer, and there is no local policy prohibiting removal of the 
allocated MR, then construct and add this visited-realm instance to the modified SDP offer; 

7) replace the connection address and port information for the media line in the modified SDP offer with the 
connection address and port information from the MR termination on the outgoing side; 

8) make any codec changes to incoming codec information, as determined in subclause 6.1.4 or 6.1.5, according to 
local policy, taking into account the procedures in clause 5.4, and insert the changed codec information into the 
SDP m-line and associated attribute lines of the modified SDP offer; 

9) if codec information is to be provided to the allocated MR for the outgoing termination, provide to the MR the 
modified codec information derived in step 8); and 

10) add to the modified SDP offer a visited-realm instance for the IP realm associated with the connection address 
and port information for the media line in the modified SDP offer, including the incoming codec information 
encoded according to clause 5.2 if any codec changes were inserted in step 8). 



6.1 .7 Allocating no primary local MR 



If the IMS-ALG decides (applying the criteria in subclauses 6.1.3 or 6.2.2) not to allocate a primary local MR, the IMS- 
ALG shall: 

1) decide according to local policy if the IMS-ALG performs any codec changes to the incoming codec 

information, as determined in subclause 6. 1 .4 or 6. 1 .5, without allocating an MR (i.e., for proactive transcoding 
without resource reservation); 



NOTE: The IMS-ALG can only make codec changes if the available SIP signalling allows the IMS-ALG to 

initiate a 2"'' SDP offer/answer transaction if necessary to allocate a transcoding MR after receipt of the 
SDP answer, as described in subclause 6.2.3. 

2) if the IMS-ALG decided in step 1) to perform any codec changes, then 

a) if there is no visited-realm instance associated with the connection address and port information for the media 
line in the received SDP offer, then construct and add this visited-realm instance; 
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b) make the codec changes to incoming codec information according to local policy, taking into account the 
procedures in clause 5.4, and insert the changed codec information into the SDP m-line and associated 
attribute lines of the modified SDP offer; and 

c) add to the modified SDP offer a visited-realm instance with the same IP realm, connection address and port 
information as the previous visited-realm instance (after a possible execution of step 3 in subclause 6. 1 .4 for 
the media line, including the incoming codec information encoded according to clause 5.2), 

3) if the IMS-ALG decided in step 1) not to perform any codec changes, then 

a) insert the incoming codec information, determined in subclause 6.1.4 or 6.1.5 into the SDP m-line and 
associated attribute lines of the modified SDP offer. 

4) use the incoming connection address, determined in subclause 6.1.4 or 6.1.5, as the connection address in the 
SDP c-line of the modified SDP offer; and 

5) use the incoming port information as determined in previous steps as port information in the SDP m-line of the 
modified SDP offer. 

6.1 .8 Allocating secondary local MRs 

According to local policy, the IMS-ALG may allocate a secondary MR for each combination of IP realm, nettype and 
addrtype on the outgoing side for which the IMS-ALG can allocate an MR context. However, if the IMS-ALG does not 
require a local MR for non-OMR reasons, the IMS ALG should only allocate a secondary MR for a combination of IP 
realm, nettype and addrtype if the IP realm, nettype and addrtype are not represented by a visited-realm or secondary- 
realm instance for the media line in the SDP offer. To allocate a secondary MR, the IMS-ALG shall: 

1) if no MR context has been allocated due to a previous SDP offer-answer exchange, allocate an MR context for 
the IP realm, nettype and addrtype on the outgoing side, using the incoming connection address and incoming 
port information for the media line, determined in subclause 6.1.4 or 6.1.5, as the remote connection address and 
port information for the incoming termination; 

2) if codec information is to be provided to the allocated MR for the incoming termination, provide to the MR the 
incoming codec information, as determined in subclause 6.1.4 or 6.1.5; 

NOTE: The IMS-ALG can defer the allocation of an MR termination at the incoming side and the related 
procedures in steps 1) and 2) until it processes the SDP answer. 

3) if any codec information is to be provided to the allocated MR for the outgoing termination, provide to the MR 
the codec information from the SDP m-line and associated attribute lines of the modified SDP offer; 

4) if the IMS-ALG did not yet add a visited-realm instance for the outgoing side (the IMS-ALG did not allocate a 
primary MR and did not perform any codec changes, see subclause 6.1.7); then 

a) if there is no visited-realm instance associated with the connection address and port information for the media 
line in the received SDP offer, then construct and add this visited-realm instance; and 

b) add to the SDP offer a visited-realm instance with the same IP realm, connection address and port 
information as the previous visited-realm instance (after a possible execution of step 3 in subclause 6.1.4 for 
the media line), 

5) add to the modified SDP offer a secondary-realm instance for the context allocated in step 1). 

6.1 .9 Forwarding SDP offer 

The IMS-ALG shall: 

1) if local policy forbids sending of OMR related attributes to the outgoing IP realm, the IMS-ALG shall delete all 
OMR related attributes from the modified SDP offer; and 

2) if the IMS-ALG has made any modifications to the received SDP offer before forwarding and the modified SDP 
offer includes OMR related attributes, the IMS-ALG shall compute checksum values as described in subclause 
5.6.3 and replace or add the "omr-s-cksum" and "omr-m-cksum" attributes for the media line. 
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The IMS-ALG forwards the SDP offer according to 3GPP TS 24.229 [4]. 

6.2 IMS-ALG handling of SDP answer 

6.2.1 General 

Upon receiving the SDP answer corresponding to the SDP offer sent in subclause 6.1, the IMS-ALG supporting OMR 
shall perform the procedures in the following subclauses for each media line in the SDP answer. 

6.2.2 IMS-ALG bypasses an allocated transcoding MR 

The IMS-ALG uses the following conditions to determine that a previously allocated primary local MR or upstream 
MR is to be bypassed and that a second SDP offer/answer transaction is needed to update the connection information on 
the outgoing side. Two examples of this procedure are given in Annex Q of TS 23.228 [3]: steps 5) and 6) of Figure 
Q.5, and steps 7) and 8) of Figure Q.7. 

If the following conditions are true: 

1) the received SDP answer includes connection address information for the media line that is a valid IP address 
other than the unspecified address (i.e., IPv4: '0.0.0.0', IPv6: 'invalid. invalid'); and 

2) it is possible to immediately initiate another SDP offer/answer transaction towards the SDP answerer with the 
available SIP signalling, 

then the IMS-ALG should re-evaluate the conditions in subclause 6.1.3, steps 1) to 4), taking into account the 
information from the originally received SDP offer, as well as the codecs received in the SDP answer as additional 
information (using the procedure in subclause 5.5 if the SDP answer includes an actual configuration), to select again 
whether to allocate a primary local MR and to recompute how many realm instances can be bypassed. The IMS-ALG 
should select to modify the previous decision if a higher number of realm instances can be bypassed. 

If the IMS-ALG selected in the previous step to modify the previous decision and 

to not allocate a primary local MR that has previously been allocated; or 

to not allocate a primary local MR and to bypass other previous realm instances than decided when previously 
evaluating subclause 6.1.3, 

then the IMS-ALG shall: 

1) apply the procedures in subclause 6. 1 .4 to bypass previous MRs or the procedures in subclause 6. 1 .5 to not 
bypass previous MRs (using information from the originally received SDP offer), depending on its 
corresponding decision; 

2) apply the procedures in subclause 6.1.7 to not allocate a primary local MR without making any codec changes; 

3) after subclauses 6.2.2 and 6.2.3 are completed as applicable for all media lines, apply the procedures in 
subclause 6.1.9 for each media line to send a second SDP offer within available SIP signalling, initiating a new 
SDP offer/answer transaction towards the SDP answerer; and 

4) upon receipt of the second SDP answer, continue handling of the second SDP answer as if it were the first, and 
reference the most recent data associated with the forwarding of the second (modified) SDP offer (i.e., incoming 
SDP information, allocated MRs and modified SDP offer) as if it occurred the first time. 

6.2.3 IMS-ALG allocates a local transcoding MR when performing 
proactive transcoding without resource reservation 

The IMS-ALG uses the procedures in this subclause if it receives an SDP answer without a realm instance, performed 
proactive transcoding without resource reservation when forwarding the SDP offer, as in step 2) of subclause 6.1.7, and 
then determines that it needs to allocate an MR for proactive transcoding. 

If all the following conditions are true: 
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1) the received SDP answer includes connection address information for the media line that is a valid IP address 
other than the unspecified address (i.e., IPv4: '0.0.0.0', IPv6: 'invalid. invalid'); 

2) the IMS-ALG performed proactive transcoding without resource reservation when previously forwarding the 
SDP offer, as in step 2) of subclause 6.1.7; 

3) the selected codec in the received SDP answer is not supported by the incoming media path and incoming codec 
information, as previously determined in subclause 6.1.4 or 6.1.5 (using information from the originally received 
SDP offer), indicating that an MR must be allocated to provide transcoding; and 

4) it is possible to immediately initiate another SDP offer/answer transaction towards the SDP answerer with the 
available SIP signalling, 

NOTE: If a second SDP offer/answer transaction cannot be initiated with available SIP signalling, the algorithm 
will fail to allocate a functioning end-to-end media path. 

then the IMS-ALG shall: 

1) if when previously handling the SDP offer it was determined in step 2) of subclause 6. 1 .3 that one or more realm 
instances can be bypassed when allocating a primary local MR (using information from the originally received 
SDP offer), then store instance-number value k=j and apply the procedures in subclause 6.1.4 to bypass previous 
MRs, else apply the procedures in subclause 6.1.5 to not bypass previous MRs (using information from the 
originally received SDP offer); 

2) apply the procedures in subclause 6. 1.6 to allocate a primary local MR; 

3) apply the procedures in subclause 6.1.8 to update allocation of any secondary MRs, if necessary; 

4) after subclauses 6.2.2 and 6.2.3 are completed as applicable for all media lines, apply the procedures in 
subclause 6.1.9 for each media line, to send a second SDP offer within available SIP signalling, and to initiate a 
new SDP offer/answer transaction towards the SDP answerer; and 

5) upon receipt of the second SDP answer, continue handling of the second SDP answer as if it were the first, and 
reference the most recent data associated with the forwarding of the second (modified) SDP offer (i.e., incoming 
information, allocated MRs and modified SDP offer) as if it occurred the first time. 

6.2.4 IMS-ALG determines steps required to complete the handling of the 
SDP answer 

The IMS-ALG performs the following steps to determine the disposition of any allocated MRs and to complete the 
handling of the SDP answer: 

1) if the received SDP answer for the media line includes a connection address with unspecified address and a 
visited-realm instance, then the IMS-ALG shall apply the procedures in subclause 6.2.5; 

2) if the received SDP answer for the media line includes a connection address with unspecified address and a 
secondary-realm instance, then the IMS-ALG shall apply the procedures in subclause 6.2.6; 

2a) If the received SDP answer for the media line includes a connection address with unspecified address and no 
visited-realm or secondary-realm instance, then the IMS-ALG shall: 

a) if necessary, update the unspecified connection address information in the SDP answer with the unspecified 
address of the appropriate type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", 
IPv6: "invahd.invalid"); 

3) if all the following conditions are true: 

a) the connection address for the media line in the received SDP answer is a valid (not unspecified) address; and 

b) the IMS-ALG did not allocate a primary local MR (i.e., executed subclause 6.1.7) when forwarding the SDP 
offer, 

then the IMS-ALG shall apply the procedures in subclause 6.2.7, and 

4) if all the following conditions are true: 
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a) the connection address for the media Hne in the received SDP answer is a valid (not unspecified) address; and 

b) the IMS-ALG allocated a primary local MR (i.e., executed subclause 6.1.6) when forwarding the SDP offer, 
then the IMS-ALG shall apply the procedures in subclause 6.2.8 to retain a primary local MR. 

6.2.5 Receiving an unspecified connection address and a visited-realm 
instance 

If the IMS-ALG receives a connection address with unspecified address and a visited-realm instance, then the IMS- 
ALG shall: 

1) If the visited-realm instance for the media line in the SDP answer has an instance-number that matches the 
visited-realm instance associated with the incoming SDP offer information, 

NOTE 1: The visited-realm instance associated with the incoming SDP offer information is either the one in the 

received SDP offer with highest instance-number (before any bypass decision is made), if one is present, 
or the one added in subclause 6.1.6 step 6) or in subclause 6.1.7 step 2a). 

NOTE 2: The IP realms in the two visited-realm instances either have the same name or are connected. 

then the IMS-ALG shall: 

replace the connection address and port information for the media line in the SDP answer with the connection 
address and port information from the visited-realm instance in the received SDP answer, and 

retain the visited-realm instance in the SDP answer, 

2) else the IMS-ALG shall: 

if necessary, update the unspecified connection address information in the SDP answer with the unspecified 
address of the appropriate type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", 
IPv6: "invalid.invalid"). 

6.2.6 Receiving an unspecified connection address and a secondary- 
realm instance 

If the IMS-ALG receives a connection address with unspecified address and a secondary-realm instance, then the IMS- 
ALG shall: 

1) if the secondary-realm instance for the media line in the SDP answer has an instance-number that matches a 
secondary-realm instance added by the IMS-ALG when applying procedures in subclause 6.1.8 then the IMS- 
ALG shall apply the procedures in subclause 6.2.8 to retain a secondary local MR, 

NOTE: The IP realms in the two secondary-realm instances either have the same name or are connected. 

2) else the IMS-ALG shall: 

if necessary, update the unspecified connection address information in the SDP answer with the unspecified 
address of the appropriate type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", 
IPv6: "invahd.invalid"). 

6.2.7 Otiner inandling winen no primary local MR allocated 

If the IMS-ALG receives (as determined in subclause 6.2.4) an SDP answer with a valid connection address after 
forwarding an SDP offer without allocating a primary local MR, then the IMS-ALG shall: 

1) If the IMS-ALG applied subclause 6. 1 .4 to bypass previous MRs when handling the forwarding of the SDP 
offer, then the IMS-ALG shall: 

a) copy into the media line of the SDP answer the visited-realm or secondary-realm instance from the media 
line of the received SDP offer that was used to populate the connection address and port information in the 
forwarded SDP offer, replacing the connection-address and port information in the instance with the 
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connection address and port information from the received SDP answer, and if the IP realm in the instance is 
a connected IP realm, replacing the IP realm name with the corresponding local IP realm name; and 

b) replace the connection address information in the SDP answer with the unspecified address of the appropriate 
type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid. invalid"), 

2) else the IMS-ALG did not bypass previous MRs when forwarding the SDP offer and the IMS-ALG shall not 
modify the SDP answer. 

NOTE: In step 1) the received SDP answer never includes a realm instance. In step 2) the SDP answer can but 
does not necessarily include a realm instance. 

6.2.8 Retaining a primary or secondary local MR 

If the IMS-ALG decides (applying the criteria in subclause 6.2.4 and subclause 6.2.6) to retain a primary or secondary 
local MR, the IMS-ALG shall: 

1) if the IMS-ALG received an SDP answer with no secondary-realm instance for the media line, then the IMS- 
ALG shall: 

NOTE: The IMS-ALG retains a primary local MR in this case. The IMS-ALG can but does not necessarily 
receive a visited-realm instance in an SDP answer when retaining a primary local MR. If present, the 
visited-realm instance can be used to identify the connected IP realm for the outgoing termination, if 
different from the IP realm of the outgoing termination. 

a) update the remote connection address and port information for the outgoing termination on the selected 
primary local MR context with the connection address and port information for the media line in the received 
SDP answer, 

b) delete the visited-realm instance from the SDP answer, if present, 

2) if the IMS-ALG received an SDP answer with a secondary-realm instance for the media line, 
then the IMS-ALG shall: 

a) update the remote connection address and port information for the outgoing termination on the selected 
secondary local MR context with the connection-address and port information from the secondary-realm 
instance in the received SDP answer; and 

b) delete the secondary-realm instance from the SDP answer, 

3) if the selected codecs in the SDP answer are not in the set of codecs associated with the incoming SDP offer 
information, as determined in subclause 6.L4 or 6.L5 when handling the SDP offer, then modify the SDP 
answer to include the codecs selected for the incoming termination of the selected local MR; 

4) if the selected MR has access to an IP realm or connected IP realm, nettype and addrtype associated with a 
visited-realm or secondary-realm instance for the media line 

such that the instance has an instance-number value k that is less than the highest instance-number value n 
associated with the media line in the incoming SDP offer information, previously determined in subclause 
6.L4or6.L5; and 

such that the instance k is associated with a codec list, determined using the procedures in clause 5.3, which 
includes the codecs selected for the incoming termination of the selected local MR in step 3) (using the 
procedure in subclause 5.5 if the SDP answer includes an actual configuration), 

then the IMS-ALG shall: 

a) store the realm instances with instance-number greater than k, which are associated with additional MRs that 
can be bypassed after selecting a codec for the incoming media path when allocating a primary local MR; 

b) apply the procedures in subclause 6.L4 to bypass additional previous MRs (using information from the 
originally received SDP offer); 
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c) insert the incoming connection address and incoming port information for the media line, as determined in 
step b), as the remote connection address and port information for the selected IP realm on the incoming 
termination of the selected MR; 

d) if necessary, modify the selected codec information in the SDP answer to be a valid response to the incoming 
SDP offer codec information determined in step b); 

e) if codec information is to be provided to the allocated MR on the incoming termination, provide to the MR 
the incoming codec information as determined in step d), 

5) If the IMS-ALG applied subclause 6. 1 .4 to bypass previous MRs when forwarding the SDP offer or in step 4b), 
then the IMS-ALG shall: 

a) copy into the media line of the SDP answer the visited-realm or secondary-realm instance from the media 
line of the received SDP offer that was used for the remote connection address and port information for the 
incoming termination on the MR, replacing the connection-address and port information in the instance with 
the local connection address and port information for the incoming termination on the selected MR, and if the 
IP realm in the instance is a connected IP realm, replacing the IP realm name with the corresponding local IP 
realm name; and 

b) replace the connection address information in the SDP answer with the unspecified address of the appropriate 
type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid. invalid"), 

6) If the IMS-ALG applied subclause 6.1.5 to not bypass previous MRs when forwarding the SDP offer, and did 
not bypass previous MRs in step 4b), then the IMS-ALG shall: 

a) replace the connection address and port information for the media line in the SDP answer with the local 
connection address and port information for the incoming termination on the selected MR. 

6.2.9 Forwarding the SDP answer 

The IMS-ALG forwards the SDP answer according to 3GPP TS 24.229 [4]. 

The IMS-ALG shall release each MR for the media line, when it is no longer potentially needed for this and any other 
forked dialog. 

6.3 IMS-ALG OMR media resource operations 
6.3.1 General 

The IMS-ALG OMR procedures as specified by subclauses 6.1 and 6.2 refer to generic MR allocation operation. When 
no MR was previously allocated, e.g. during the initial SDP offer/answer exchange, this allocation will result in the 
allocation of one or more local media termination point pairs (ingress and egress) - one for the primary IP realm and 
possible additional terminations points for secondary IP realms. 

Subsequent SDP offer/answer exchanges may result in the decision that a local MR is needed. If a local MR was not 
previously allocated, then one will now be allocated. If a local MR was previously allocated that matches the resource 
information needed, then the previously allocated resource will be used. If the previously allocated local MR does not 
match the resource information needed, then the local MR will be modified to meet the current need. 

If it is determined that local MR may be by-passed or no longer needed, then any previously allocated local MRs will be 
deallocated. 



6.3.2 IMS-ALG operations 



The OMR MR procedures in this document are applicable to the following IMS entities that perform as IMS-ALG 
using the media resource interface operations as indicated. 

- An IBCF acting as an IMS-ALG controlling a TrGW using the Ix interface as defined by 3GPP TS 29.162 [16] 
and 3GPP TS 29.238 [9]: 

Reserve TrGW Connection Point; 
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Configure TrGW Connection Point, 

Reserve and Configure TrGW Connection Point; and 

Release TrGW Connection Point. 

- A P-CSCF acting as IMS-ALG controlling an IMS-AGW using the Iq interface as defined by 3GPP TS 23.334 
[15] and 3GPPTS 29.334 [10]: 

Reserve AGW Connection Point; 

Configure AGW Connection Point; 

Reserve and Configure AGW Connection Point; and 

Release AGW Connection Point. 

An AS acting as B2BUA and adapting IMS-ALG procedures to control an MRF shall use one or more of the 
following: 

IETF RFC 4240 [11] conference service; 

- IETF RFC 41 17 [19]; and 

- IETF RFC 3260 [12] and IETF RFC 6505 [13]. 

6.4 Handling of connected IP realms 

For each IP realm to which a controlled MR has direct access, the IMS-ALG supporting OMR may be provisioned with 
a list of the names of connected IP realms, if any. The IMS-ALG shall determine if an IP realm is connected to a local 
IP realm based only on provisioning. 

NOTE 1: The OMR algorithm assumes that a first IMS-ALG or UA sending an SDP offer that offers connectivity 
via a local IP realm will accept from a second IMS-ALG or UA an SDP answer with an address in a 
connected IP realm, even if the first IMS-ALG or UA does not have provisioned information about the 
connected IP realm. 

NOTE 2: Connected IP realm lists only need to be provisioned at certain OMR-capable nodes. For example, it is 

preferred that an IBCF whose TrGW has connectivity to multiple peer networks via bilateral interconnect 
be provisioned with connected IP realm information. 



7 UA Procedures 

7.1 UA sending an SDP offer 

Upon preparing an SDP offer for sending to begin an SDP offer/answer transaction, a UA supporting OMR shall 
additionally: 

1) add to the SDP offer a visited-realm instance for the IP realm associated with the connection address and port 
information for the media line in the SDP offer; 

2) for each combination of IP realm, nettype and addrtype on the outgoing side for which the UA can allocate an 
MR termination according to local policy, if the IP realm, nettype and addrtype are not associated with the media 
line in the SDP offer, allocate an MR termination for the IP realm, nettype and addrtype on the outgoing side, 
using the same codecs associated with the media line; 

3) add to the SDP offer a secondary-realm instance for each termination allocated in step 2); and 

4) compute a checksum values as described in subclause 5.6.3 and add the "omr-s-cksum" and "omr-m-cksum" 
attributes for the media line. 

The UA then sends the SDP offer according to 3GPP TS 24.229 [4]. 
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7.2 UA receiving an SDP offer 

7.2.1 General 

Upon receiving an SDP offer and selecting a codec for the media line, a UA supporting OMR shall perform the 
procedures specified in subclauses 7.2.2 and 7.2.3, and then send the SDP answer according to 3GPP TS 24.229 [4]. 

7.2.2 Validating the incoming SDP offer 

If any of the following conditions are true: 

1) the SDP offer includes any OMR attributes for the media line, but no visited-realm instance; 

2) the connection-address and port information in the visited-realm instance with the highest value of instance- 
number for the media line does not match the connection address and port information for the media line; or 

3) one of the following checksum comparison failures are true: 

the "omr-m-cksum" attribute does not match the checksum value computed for the media line as described in 
subclause 5.6.3; or 

based on local policy, if the "omr-m-cksum" attribute matches the computed media line checksum, but the 
"omr-s-cksum" attribute does not match the checksum value computed for the session level Unes as described 
in subclause 5.6.3, 

then the UA shall remove all OMR related attributes associated with the media Une. 

7.2.3 UA may choose an alternate realm instance to bypass an upstream 
MR 

If all the following conditions are true: 

1) the UA can make available a media termination in an IP realm, nettype and addrtype such that this IP realm or a 
connected IP realm, nettype and addrtype match the IP realm, nettype and addrtype of a visited-realm or 
secondary-realm instance for the media line in the SDP offer; 

2) the instance does not match the connection address and port information in the SDP offer; and 

3) the instance supports the codec selected by the UA, 
then the UA shall: 

1) select the visited-realm or secondary-realm instance with the lowest value of instance-number such that the UA 
can make available a media termination in the IP realm or connected IP realm, nettype and addrtype that matches 
the IP realm, nettype and addrtype of the instance and the instance supports the codec selected by the UA; 

2) allocate a media termination in the selected IP realm, nettype and addrtype; 

3) copy into the media line of the SDP answer the selected visited-realm or secondary -realm instance from the 
media line of the received SDP offer, replacing the connection-address and port information in the instance with 
the local connection address and port information for the allocated termination, and if the IP realm in the 
instance is a connected IP realm, replacing the IP realm name with the corresponding local IP realm name; and 

4) replace the connection address information in the SDP answer with the unspecified address of the appropriate 
type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid.invalid"). 
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7.3 UA receiving an SDP answer 

7.3.1 General 

Upon receiving the SDP answer corresponding to the SDP offer sent in subclause 7.1, the UA supporting OMR shall 
perform the procedures specified in either subclause 7.3.2 if the SDP answer included a realm instance or subclause 
7.3.3 if the SDP answer did not include a realm instance. 

7.3.2 Receiving SDP answer witin an unspecified connection address 

If the received SDP answer for the media line includes an unspecified connection address and a secondary -realm 
instance with an instance-number that matches a visited-realm or secondary-realm instance for the media line from the 
SDP offer, then the UA shall: 

NOTE: The IP realms in the two realm instances either have the same name or are connected. 

1) update the remote connection address and port information for the selected outgoing termination with the 
connection-address and port information from the visited-realm or secondary-realm instance in the received SDP 
answer; and 

2) release any other MR apart from the selected MR allocated for the media line, when it is no longer potentially 
needed for any other forked dialog. 

7.3.3 Receiving SDP answer witin a valid connection address 

If the received SDP answer includes a valid (not unspecified) connection address for the media line, then the UA shall: 

1) update the remote connection address and port information for the primary outgoing termination with the 
connection address and port information from the received SDP answer; and 

2) release any secondary MR allocated for the media line, when it is no longer potentially needed for any other 
forked dialog. 

7.4 UA OMR media resource operations 
7.4.1 General 

The UA OMR procedures as specified by subclauses 7.1, 7.2, and 7.3 refer to generic MR allocation operation. This 
allocation will result in the allocation of a local media termination associated with the selected IP realm. 

Subsequent SDP offer/answer exchanges may result in either the exact same local MR being allocated or possibly a 
different local MR. If the UA is able to determine that the same resource information is being requested, the existing 
allocated local MR will be used. If the previously allocated local MR does not match the resource information needed, 
then the local MR will be modified to meet the current need. 



7.4.2 UA operations 



The OMR MR procedures in this document are applicable to the following IMS entities that perform as UA using the 
media resource interface operations as indicated. 

An AS acting as B2BUA and adapting UA procedures to control an MRF shall use one or more of the following: 

IETF RFC 4240 [11] conference service and tone/announcement service; 

- IETF RFC 5552 [18]; and 

- IETF RFC 3260 [ 1 2] and IETF RFC 6505 [ 1 3] . 

- An MGCF acting as an UA controlhng an IM-MGW using the Mn interface as defined by 3GPP TS 29.163 [17] 
and 3GPPTS 29.332 [14]: 
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Reserve IMS Connection Point; 

Configure IMS Connection Point; 

Reserve and Configure IMS Connection Point; and 

Release IMS Connection Point. 

7.5 Handling of connected IP realms 

For each IP realm to which a controlled MR has direct access, the UA supporting OMR may be provisioned with a list 
of the names of connected IP realms, if any. The UA shall determine if an IP realm is connected to a local IP realm 
based only on provisioning. 

NOTE 1: The OMR algorithm assumes that a first IMS-ALG or UA sending an SDP offer that offers connectivity 
via a local IP realm will accept from a second IMS-ALG or UA an SDP answer with an address in a 
connected IP realm, even if the first IMS-ALG or UA does not have provisioned information about the 
connected IP realm. 

NOTE 2: Connected IP realm lists only need to be provisioned at certain OMR-capable nodes. For example, it is 

preferred that an IBCF whose TrGW has connectivity to multiple peer networks via bilateral interconnect 
be provisioned with connected IP realm information. 



8 Subsequent SDP offer/answer transactions 



8.1 



General 



Any UA or IMS-ALG controlling a media stream can initiate another SDP offer/answer transaction at any time after 
first establishing the media flow, to modify characteristics of the media flow. For example, a media endpoint (IP 
address) can change, the preferred codec can change, or a server can select to insert a media function such as a tone 
generator or conference focus. Since OMR applies independently to each SDP offer/answer transaction, it is possible 
for the OMR algorithm to create a different media configuration with each subsequent SDP offer/answer transaction, 
particularly if the transaction is initiated by a different entity in the network. It is desirable to minimize the changes in 
the outcome of the OMR algorithm during subsequent SDP offer/answer transactions to those necessary to support any 
changes in the requested characteristics of the media flow. 

8.2 Procedures to minimize changes in OMR outcome 

If an IMS-ALG receives an SDP offer, and a previous OMR procedure resulted in the establishment of a media path 
from an MR controlled by that IMS-ALG in the forward direction through a different IP realm than the next IP realm in 
the signalling path for the SDP offer, the IMS-ALG should add a secondary realm instance corresponding to that MR 
and the IP realm of the media path to the forwarded SDP offer. 

If a UA sends a new SDP offer within a dialog where a previous OMR procedure established a media path using a 
secondary IP realm, the UA should add a secondary realm instance corresponding to the same secondary IP realm in the 
new SDP offer. 

If an IMS-ALG receives an SDP offer, and a previous OMR procedures resulted in the establishment of a media path 
from an MR controlled by that IMS-ALG in the backward direction, the IMS-ALG should consider and preferentially 
select from the options available in subclause 6.1.3 the earliest incoming realm instance with the same IP realm or a 
connected IP realm, nettype and addrtype as used for the existing media path in the backward direction, unless a clearly 
superior option is available according to local policy. 

If a UA receives a new SDP offer within a dialog where a previous OMR procedure established a media path, the UA 
should consider and preferentially select from the options available in subclause 7.2.3 the earliest realm instance with 
the same IP realm or a connected IP realm, nettype and addrtype as used for the existing media path in the backward 
direction, unless a clearly superior option is available according to local policy. 

IMS-ALGs and UAs should be symmetrically provisioned with connected IP realm information. 
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If a transcoding option at a local MR was selected in a previous SDP offer/answer transaction, the corresponding IMS- 
ALG should again offer the transcoding options currently applied at this MR during subsequent SDP offer/answer 
transactions, using proactive transcoding with resource reservation. 

If a transcoding option at a local MR was not selected in a previous SDP offer/answer transaction, the corresponding 
IMS-ALG may according to local policy continue to offer transcoding options during subsequent SDP offer/answer 
transactions. If the IMS-ALG offers transcoding options during a subsequent SDP offer/answer transaction and none of 
them were previously selected, it should perform transcoding without resource reservation. 
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Annex A (informative): 
Signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Optimized Media Routeing (OMR) based on the Session Initiation 
Protocol (SIP) and the Session Description Protocol (SDP). The OMR specific SDP syntax is described in 3GPP TS 

24.229 [4]. 



A.2 Introduction 

The signalling flows in this annex are based on IP realm and IP structure in Figure A.2-1. 




Home IMS network Y: 
Realm Yb.operatorY.net 



Intermediate IMS 
CN subsystem entities 

z 



Realm: X.operatorX.net, > 




Visited network X: 
Realm Xa.operatorXriel 



PCRF 
■►IPDNGW;^ 



UE-B 



192.0.2.4 



-► : Controll signalling path 
■► : Media path after OMR 



Figure A.2-1 : IP realm and IP structure. 

Operator X and operator Y have an agreement to allow roaming users and to use OMR as much as possible. 

UE-A and UE-B are mobile users roaming into the visited network X. IP addresses etc. are obtained as described in 
3GPPTS 24.229 [4]. 

The operator X implements the IBCF policy to allow OMR optimization of anchoring if originating UE is a visiting/ 
roaming user respectively if terminating UE is a visiting/roaming user. 

The operator Y implements the IBCF policy to allow OMR optimization of anchoring if home UE is visiting/roaming in 
another network. 
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A.3 Media bypassing all IMS-ALGs 
A.3.1 General 

This subclause provides an example of a call where the media is bypassing all IMS-ALG and sent directly between the 
UEs. 

A.3. 2 Message flow 

This subclause describes the scenario when two mobile user A and B roams into a visited network X and both users 
belongs to the same operator Y. 

Preconditions: 

Both user A and B are registered to the Home IMS network Y via the visited operator X network; 

the visited operator X and the operator of user A and B IMS home network Y have an agreement to allow media 
to be bypassed using OMR; 

both user A and B are connected to IP realm Xa of the visited operator network X; 

the AMR codec is allowed and accepted by all involved entities; and 

no B2BUA manipulating SDP is connected in the intermediate IM CN subsystem. 

Figure A. 3. 2-0 shows the message flow for the scenario. 
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visited.realm2Y-X34.24.1.1, 

visited-realm:3Yb 1901.15.2] 


45. 200 OK 


44. 200 OK 


(UPDATE) 

■ [AMR, ~ 

c^o.o.o.a 

visited-reaim:1 Xa 192.0.2.4] 


(UPDATE) 

-• [AMR, 
0=0.0.0.0, 
visited<ealtn:1 Xa 1920.2.4] 



-52. 180- 



_60.200OK_ 
(INVITE) 



-69. ACK- 



■ audio media- 



IBCF-4 

13.24.1.4 192.0.2.: 



6. INVITE 

[AMR, 

0=13.24.1.1, 

"visited-reainitl Xa* 

192.0.2.1, 

visited.realtn:2X-Y 

13.24.1.1] 

11.183 

[AMR, 

• 0=0.0.0.0, - 

visited-realni:1 Xa 

192.02.4] 



-22. PRACK^ 

27. 200 0K_ 

*" (PRACK) 



38. UPDATE 

[AMR, 

0=13.24.1.1, 

" visited-fealm:1 Xa * 

1920.2.1, 

visited.realtn:2 Y-X 

13.24.1.1] 



43. 200 OK 

(UPDATE) 

« [AMR, 
0=0.00.0, 
visited-realni:1 Xa 
19202.4] 



-51.180- 



59. 200 0K_ 
*" (INVITE) 



-70. ACK— ^ 



P-CSCF B 



7. INVITE 

[AMR, 

- c^l 92.02.1, • 

visited-realm:1 Xa 

192.0.2.1] 



10. 183 

- [AMR, - 
0=192.0.2.4] 



-23. PRACK^ 

26. 200 0K_ 
*" (PRACK) 



39. UPDATE 

[AMR, 

- 0=192.0.2.1, • 

visited<ealtn:1 Xa 

192.0.2.1] 



42. 200 OK 
^ (UPDATE). 

[AMR, 
0=192.0.2.4] 



-50. 180- 



58. 200 0K_ 
"" (INVITE) 



-71.ACK-^ 



UE-B 

92.0.2.4 



8. INVITE 
[0=192.0.2.1] 



9. 183 

[0=192.0.2.4] 



-24. PRACK*- 

25. 200OK_ 

*" (PRACK) 



40. UPDATE 

[AMR, ► 

0=192.0.2.1] 



41. 200 OK 
^(UPDATE)- 

[0=192.0.2.4] 



-49. 180 



57. 200 0K_ 

*" (INVITE) 



-72. ACK- 



Figure A.3.2-1 : Signalling flow for media bypassing all IMS ALGs. 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 
The steps of the flow are as follows: 

1. INVITE request (UE-A to P-CSCF-A) - see example in table A.3.2-1. 

The UE-A sends a SIP INVITE request including an SDP offer according to 3GPP TS 24.229 [4]. 
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Table A.3.2-1 : SIP INVITE request (UE-A to P-CSCF-A) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



2. INVITE request (P-CSCF-A to IBCF-1) - see example in table A.3.2-1. 

The P-CSCF-A uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no MR could be bypassed and no 
MR is allocated. 

The P-CSCF-A: 

uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

uses the port information from the SDP m-line as incoming port information in subsequent steps; 

uses the codec information from the SDP m-line in subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer, and 

use the incoming port information as port information in the SDP m-line of the modified SDP offer. 

The P-CSCF-A then selects an IBCF, IBCF-1, in the IP realm "Xa.operatorX.net" and forwards the INVITE 
request with the SDP offer to the IBCF-1 according to 3GPP TS 24.229 [4]. 

3. INVITE request (IBCF-1 to IBCF-2) - see example in table A.3.2-3 

The IBCF-1 uses the procedures in subclauses 6.1.5, 6.1.6 and 6.1.9 since no previous realm instance offers an 
opportunity to bypass a previous MR and a local MR is required for IP realm matching. 

The IBCF-1: 

uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

uses the port information from the SDP m-line as incoming port information in subsequent steps; 

uses the codec information from the SDP m-line in subsequent steps; 

allocates an MR context with access to the IP realms and addrtypes associated with the incoming and 
outgoing signalling paths; 

inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information; 
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replaces the connection address and port information for the media hne in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

constructs and adds a visited-realm instance for the media Hne in the received SDP offer to the modified SDP 
offer; 

adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer, including the incoming codec; and 

computes a checksum value for the media line as described in subclause 5.6.3 and adds the "omr-m-cksum" 
and "omr-s-cksum" attributes for the media line. The "omr-s-cksum" is set to "0" since there are no session 
attributes to compute the checksum on. 

The IBCF-1 then selects an IBCF, IBCF-2, in the IP realm "X-Y.operatorX.net" and forwards the INVITE 
request with the SDP offer to the IBCF-2 according to 3GPP TS 24.229 [4]. 

Table A.3.2-3: SIP INVITE request (IBCF-1 to IBCF-2) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S15 IN IP4 192.0.2.1 

s= 

t = 

c=IN IP4 13 .24 .1.1 

m=audio 62111 RTP/AVP 9S 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :9G telephone- event 

a=maxptime : 2 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 X- Y. operator .netX IN IP4 13.24.1.1 62111 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



4-5. INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) - see example in 
table A.3.2-4. 

The IBCF-2 uses the procedure in subclauses 6.1.5, 6.1.6 and 6.1.9 since no realm instance offers an opportunity 
to bypass a previous MR and a local MR is required for IP realm matching. 

The IBCF-2: 

uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

uses the port information from the SDP m-line as incoming port information in subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information in subsequent steps; 

allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
and outgoing signalling paths, respectively, applying procedures as described in subclause 6.3, 

insert the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information; 

replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 
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adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 
address and port information for the media Hne in the modified SDP offer, including the incoming codec; and 

computes a checksum value for the media line as described in subclause 5.3.4 and adds the "omr-m-cksum" 
and "omr-s-cksum" attributes for the media line The "omr-s-cksum" attribute is set to "0" since there are no 
session attributes to compute the checksum on.. 

The IBCF-2 forwards the INVITE request to the intermediate IMS CN subsystem entities in IP realm 
"Yb.operatorY.net" according to 3GPP TS 24.229 [4]. 

None of the intermediate IMS CN subsystem entities manipulated with the SDP offer but the identity of 
user B ©operator Y.net in the Request-URI is change to the contact address, i.e. UE-B@operatorX.net. 

The intermediate IMS CN subsystem entities select an IBCF, IBCF-3, and forward the INVITE request with the 
SDP offer to the IBCF-3 according to 3GPP TS 24.229 [4]. 

Table A.3.2-4: SIP INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S15 IN IP4 192.0.2.1 

s= 

t = 

c=IN IP4 190.1.15.2 

m=audio 11324 RTP/AVP 96 07 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :9G telephone- event 

a=maxptime : 2 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 X- Y. operator .netX IN IP4 13.24.1.1 62111 

a=visited-realm:3 Yb.operatorY.net IN IP4 190.1.15.2 11324 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



6. INVITE request (IBCF-3 to IBCF-4) - see example in table A.3.2-6. 

The IBCF-3 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-2, and bypass is allowed according to operator X and operator Y 
agreements, and the previous realm instance match the outgoing IP realm so that no local MR is required. 

The IBCF-3: 

uses the connection address and port information for the media line in the SDP offer with the connection- 
address and port information from the selected instance 2 as incoming connection address and incoming port 
information for the media line; 

- deletes the visited-realm instance 3; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; and 
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computes a checksum value for the media line as described in subclause 5.3.4 and adds the "omr-m-cksum" 
and "omr-s-cksum" attributes for the media line. The "omr-s-cksum" attribute is set to "0" since there are no 
session attributes to compute the checksum on. 

The IBCF-3 then selects an IBCF, IBCF-4, in the IP realm "X.operatorX.net, Y. operatorY.net" and forwards the 
SDP offer according to 3GPP TS 24.229 [4] to IBCF-4. 

Table A.3.2-6: SIP INVITE request (IBCF-3 to IBCF-4) 



INVITE SIP: sipiUE- BaoperatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 13.14.1.1 

m=audio 62111 RTP/AVP 96 07 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 X- Y. operator .netIN IP4 13.24.1.1 62111 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



7. INVITE request (IBCF-4 to P-CSCF B) - see example in table A.3.2-7. 

The IBCF-4 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-1, and the previous realm instance match the outgoing IP realm so 
that no local MR is required. 

The IBCF-4: 

uses the connection address and port information for the media line in the SDP offer with the connection- 
address and port information from the selected instance 1 as incoming connection address and incoming port 
information for the media line; 

deletes the visited-realm instance 2; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; and 

computes a checksum value for the media line as described in subclause 5.3.4 and adds the "omr-m-cksum" 
and "omr-s-cksum" attributes for the media line. The "omr-s-cksum" attribute is set to "0" since there are no 
session attributes to compute the checksum on. 

The IBCF-4 forwards the INVITE request with the SDP offer to the P-CSCF-B, in the IP realm 
"X.operatorX.net" according to 3GPP TS 24.229 [4]. 
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Table A.3.2-7: SIP INVITE request (IBCF-4 to P-CSCF B) 



INVITE SIP: sip: UE-BOoperatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Xa . operatorX . net IN IP4 192.0.2.1 49170 

a=omr-m-cksum: ( . . ) 

a=omr-s-cksum: 



8. INVITE request (P-CSCF to UE- B) - see example in table A.3.2-8. 

The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR is required to match the incoming realm to the outgoing realm. 

uses the connection-address from the SDP c-line as incoming connection-address; 

uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; and 

according to the local policy, deletes the visited-realm "visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 
49170", the "omr-m-cksum:(...)" and the "omr-s-cksum=:0" attributes from the SDP offer. 

The P-CSCF-B forwards the INVITE request with the SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 
Table A.3.2-8: SIP INVITE request (P-CSCF to UE-B) 



INVITE SIP: sip:UE-B®operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



9. 183 (Session Progress) response (UE-B to P-CSCF-B) - see example in table A.3.2-9. 
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The UE accepts the codec and sends a 183 (Session Progress) response with an SDP answer indicating that 
resources are not yet available to P-CSCF-B according to 3GPP TS 24.229 [4]. 

Table A.3.2-9: 183 (Session Progress) response (UE-B to P-CSCF-B) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 192 .0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 



10. 183 (Session Progress) response (P-CSCF-B to IBCF-4) - see example in table A.3.2-9 

The P-CSCF-B uses the procedures in subclauses 6.2.7 and 6.2.9 since the connection address is valid and no 
primary local MR was allocated. 

The P-CSCF-B:- does not modify the SDP answer and forwards the 183 (Session Progress) response with the 
SDP answer to lBCF-4 according to 3GPP TS 24.229 [4]. 

11. 183 (Session Progress) response (IBCF-4 to IBCF-3) - see example in table A.3.2-11 

The lBCF-4 uses the procedures in subclause 6.2.7 and 6.2.9 since the connection address is valid and no 
primary local MR was allocated. 

The IBCF-4: 

copies into the media line of the SDP answer the visited-realm instance 1 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer; and 

replaces the connection address information in the SDP answer with the unspecified IPv4 address. 

The IBCF-4 forwards the 183 (Session Progress) response with SDP answer to IBCF-3 according to 3GPP TS 

24.229 [4]. 
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Table A.3.2-11 183 (Session Progress) response (IBCF-4 to IBCF-3) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 0.0.0.0 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.4 



12-13. 183 (Session Progress) response (IBCF-3 to IBCF-2 via intermediate IMS CN subsystem entities) - see 
example in table A.3.2-11 

The IBCF-3 uses the procedures in subclauses 6.2.5 and 6.2.9 since the SDP answer contained an unspecified 
connection address and a realm instance matching one in the received SDP offer and since no primary local MR 
was allocated. 

The IBCF-3: 

copies into the media line of the SDP answer the visited-realm instance 1 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer. 

The IBCF-3 then forwards the 183 (Session Progress) response with SDP answer to intermediate IMS CN 
subsystem entities according to 3GPP TS 24.229 [4]. 

The intermediate IMS CN subsystem entities do not modify the SDP answer and forwards the 183 (Session 
Progress) response with SDP answer to IBCF-2 according to 3GPP TS 24.229 [4]. 

14. 183 (Session Progress) response (IBCF-2 to IBCF-1) - see example in table A.3.2-11 

The IBCF-2 uses the procedures in subclauses 6.2.5 and 6.2.9 since the SDP answer contained an unspecified 
connection address and a realm instance matching one in the received SDP offer and the local MR allocated in 
step 4 can be bypassed. 

The IBCF does not modify the SDP answer since the visited-realm instance does not match the information in 
the SDP offer. 

The IBCF-2 forwards the 183 (Session Progress) response with SDP answer to IBCF-1 according to 3GPP TS 

24.229 [4]. 

The IBCF-2 retains the primary local MR allocated in step 4, until it is no longer potentially needed for this and 
any other forked dialog. 

15. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) - see example in table A.3.2-15 

The IBCF-1 uses the procedures in subclauses 6.2.5 and 6.2.8 since the SDP answer contained an unspecified 
connection address and a realm instance matching one in the received SDP offer and the local MR allocated in 
step 4 can be bypassed. 

The IMS-ALG: 
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replaces the connection address and port information for the media line in the SDP answer with the 
connection address and port information from the visited-realm instance in the received SDP answer. 

The IBCF-1 forwards the 183 (Session Progress) response with SDP answer to P-CSCF-A according to 3GPP 
TS 24.229 [4]. 

The IBCF-1 retains the primary local MR allocated in step 3, until it is no longer potentially needed for this and 
any other forked dialog. 

Table A.3.2-15: 183 (Session Progress) response (IBCF-1 - P-CSCF-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 192 .0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 



16. 183 (Session Progress) response (P-CSCF-A to UE-A) - see example in table A.3.2-15 

The P-CSCF-A: 

forwards the 183 (Session Progress) with the SDP answer to the UE-A according to 3GPP TS 24.229 [4] ; 
and 

deletes the visited-realm instance according to local policy. 

17-24. PRACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediate IMS CN subsystem 
entities, IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-A acknowledge the reception of the SDP offer and the 183 (Session Progress) response by means of a 
PRACK request. 

25-32. 200 (OK) response to the PRACK request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediate IMS CN subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

The UE-B acknowledges the reception of the PRACK request by means of a 200 (OK) response. 

33. UPDATE request (UE-A to P-CSCF-A) - see example in table A.3.2-33. 

When the UE-A has got resources reserved the UE-A sends an UPDATE request. 

The SDP offer in the UPDATE the request is the same as the SDP offer in the INVITE request in the step 1 with 
the only exception that "a=curr:qos local none" is now changed to "a=curr:qos local sendrecv". 
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Table A.3.2-33: UPDATE request (UE-A to P-CSCF-A) 



UPDATE SIP: sipiUE- AOoperatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 192 .0.2.1 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 



34-40. UPDATE request (P-CSCF-A to UE-B via IBCF-1, IBCF-2, intermediate IMS CN subsystem entities, 
IBCF-3, IBCF-4 and P-CSCF-B). 

34) When the P-CSCF-A receives the UPDATE request the P-CSCF-A performs the same actions as P-CSCF-A 
in step 2. 

35) When the IBCF-1 receives the UPDATE request the IBCF-1 performs the same actions as in step 3. 

36) When the IBCF-2 receives the UPDATE request the IBCF-2 performs the same actions as in step 4. 

37) Intermediate IMS CN subsystem entities do not manipulate the SDP offer. 

38) When the IBCF-3 receives the UPDATE request the IBCF-3 performs the same actions as in step 6. 

39) When the IBCF-4 receives the UPDATE request the IBCF-4 performs the same actions as in step 7. 

40) When the P-CSCF-B receives the UPDATE request the P-CSCF-B performs the same actions as in step 8. 

41, 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B) - see example in table A.3.2-41, 

The UE-B acknowledges the reception of the UPDATE request by means of a 200 (OK) response containing 
SDP answer. 
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Table A.3.2-41 : 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B). 



SIP/2.0 200 OK 

Via: 

To: <sip :user_A@operator_Y.net>; tag=171828 

From: <sip :user_B@operator_Y.net>; tag=543210 

Call -ID: Cb03a0s0 9a2sdfglkj 490237 

CSeq: 

P -Preferred- Identity : 

Contact : sip:UE-B@operatorX.net;gr=urn:uuid: 3 54f af -7dad-22al-bl2 3-8aOd21f 6 76f 

Allow: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

c=IN IP4 192.0.2.4 

m=audio 49170 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



42-48. 200 (OK) response to the UPDATE request (P-CSCF-B to UE-A via IBCF-4, IBCF-3, intermediate 
IMS CN subsystem entities, IBCF-2 and IBCF-1). 

42. When P-CSCF-B receives the 200 (OK) response to the UPDATE request the P-CSCF-B performs the same 
actions as in step 10. 

43. When IBCF-4 receives the 200 (OK) response to the UPDATE request the IBCF-4 performs the same 
actions as in step 1 1 . 

44. When IBCF-3 receives the 200 (OK) response to the UPDATE request the IBCF-3 performs the same 
actions as in step 12. 

45. The intermediate IMS CN subsystem entities do not manipulate the SDP answer. 

46. When IBCF-2 receives the 200 (OK) response to the UPDATE request the IBCF-2 performs the same 
actions as in step 14. 

47. When IBCF-1 receives the 200 (OK) response to the UPDATE request the IBCF-1 performs the same actions 
as in step 15. 

48. When P-CSCF-A receives the 200 (OK) response to the UPDATE request the P-CSCF-A performs the same 
actions as in step 16. 

49-56. 180 (Ringing) response (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, intermediate IMS CN 
subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

No OMR specific action is required. 

57-64. 200 (OK) response to the INVITE request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediated IMS CN subsystem, IBCF-2, IBCF-1 and P-CSCF-A). 

The User B accepts the call and the UE-B sends a 200 (OK) response to the INVITE request. No OMR specific 
action is required. 

65-72. ACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediated IMS CN subsystem, 
IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-B acknowledges the reception of the 200 (OK) response by means of a 200 (OK) response. 
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A.4 IMS-ALG allocates a local transcoding MR when 
performing proactive transcoding without resource 
reservation 



A.4.1 General 



This subclause provides an example of a call where a transcoding MR adds the AMR codec to the initial SDP offer 
without MR allocation. 

The UE selects the added codec and the IMS-ALG needs to reserve MR and send an UPDATE request with the IP 
address and port number of the allocated MR. 

The IMS-ALG is transcoding between the AMR-WB codec and the AMR codec when the call is established. 

Figure A.4.1-1 shows the realm and IP structure used in this example. 
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Figure A.4.1-1 : IP realm and IP structure. 



A.4. 2 Message flow 



The user A at UE-A and the user B at UE-B are roaming into a visited network X and both users belong to the same 
operator Y. 

Preconditions: 

Both user A and B are registered to the Home IMS network Y via the visited operator X network; 

the visited operator X and the operator Y have an agreement to allow media to be bypassed using OMR; 

both user A and B are connected to the realm "Xa.operatorX.net" of the visited operator network X; 



£75/ 



3GPP TS 29.079 version 11.3.0 Release 11 



42 



ETSI TS 129 079 V1 1.3.0 (2013-04) 



the AMR-WB codec is allowed and accepted by all involved entities. However, the local policy of operator X is 
that the AMR codec shall always be included in the initial SDP offers from a UE in the operator X network; and 

no B2BUA manipulating SDP is connected in the intermediate IM CN subsystem. 

Figure A.4.2-1 shows the message flow for the scenario. 
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Figure A.4.2-1 : Message flow for proactive transcoder without resource reservation. 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 

The steps of the flow are as follows: 

1. INVITE request (UE-A to P-CSCF-A) - see example in table A.4.2-1. 

The UE-A sends a SIP INVITE request according to 3GPP TS 24.229 [4]. The INVITE request includes an SDP 
offer proposing the use of the AMR-WB codec and inband DTMF. 
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Table A.4.2-1 : SIP INVITE request (UE-A to P-CSCF-A) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:20 

C=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 24 



2. INVITE request (P-CSCF-A to IBCF-1) - see example in table A.4.2-1. 

The P-CSCF-A uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no MR could be bypassed and no 
MR is allocated. 

The P-CSCF-A: 

uses the connection-address from the SDP c-line as incoming connection-address; 

uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer, and 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer. 

The P-CSCF-A then selects an IBCF, IBCF-1, in the realm "Xa.operatorX.net" and forwards the INVITE request 
with the SDP offer to the IBCF-1 according to 3GPP TS 24.229 [4]. 

3. INVITE request (IBCF-1 to IBCF-2) - see example in table A.4.2-3 

The IBCF-1 uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers an 
opportunity to bypass a previous MR and a local MR is not required for realm matching. The IBCF-1 has access 
to a trancoding MR. 

The IBCF-1: 

uses the connection-address from the SDP c-line as incoming connection-address; 

uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line; 

constructs and adds to the modified SDP offer a visited-realm instance 1 for the media line associated with 
the connection address and port information for the media line in the received SDP offer; 
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makes the codec changes to incoming codec information according to local policy, taking into account the 
procedures in clause 5.4, and inserts the AMR codec information into the SDP m-line and associated attribute 
lines of the modified SDP offer; 

adds to the modified SDP offer a visited-realm instance 2 with the same IP realm, connection address and 
port information as in the previous visited-realm instance 1 for the media line including the incoming codec 
information; and 

computes a checksum value for the media line as described in subclause 5.6.3 and adds omr-m-cksum and 
omr-s-cksum attributes for the media line. The omr-s-cksum is set to "0" since there are no session line 
attributes left to calculate the checksum on. 

The IBCF-1 then selects an IBCF, IBCF-2, in the realm "Xa.operatorX.net" and forwards the INVITE request 
with the SDP offer to the IBCF-2 according to 3GPP TS 24.229 [4]. 

Table A.4.2.2-3: SIP INVITE request (IBCF-1 to IBCF-2) 



INVITE SIP: user_B®operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm: 1 Xa . operatorX . net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=omr-codecs :2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 telephone-event 

a=omr-m-att :2 rtpmap:97 AMR-WB/16000/1 

a=omr-m-att : 2 fmtp:97 mode-change-capability=2 ; max-red=220 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



4-5. INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) - see example in 
table A.4.2-4. 

The IBCF-2 uses the procedure in subclauses 6.1.5, 6.1.6 and 6.1.9 since no realm instance offers an opportunity 
to bypass a previous MR and a local MR is required for realm matching. 

The IBCF-2: 

uses the connection-address from the SDP c-line as incoming connection-address; 
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uses the port information from the SDP m-hne as incoming port information; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; 

allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
connection address and port information and outgoing signalling paths, respectively, applying procedures as 
described in subclause 6.3, 

insert the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information; 

replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

adds to the modified SDP offer a visited-realm instance 3 for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer; 

computes a checksum value for the media line as described in subclause 5.6.3 and adds the omr-m-cksum 
and omr-s-cksum attributes for the media line. The omr-s-cksum attribute is set to "0" since there are no 
session line attributes to compute the checksum on; and 

forwards the INVITE request to the intermediate IMS CN subsystem entities in realm "Yb.operatorY.net" 
according to 3GPP TS 24.229 [4]. 

None of the intermediate IMS CN subsystem entities manipulated with the SDP offer but the identity of 
user B ©operator Y.net in the Request-URI is change to the contact address, i.e. UE-B@operatorX.net. 

The intermediate IMS CN subsystem entities select an IBCF, IBCF-3, and forward the INVITE request with the 
SDP offer to the IBCF-3 according to 3GPP TS 24.229 [4]. 
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Table A.4.2-4: SIP INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) 



INVITE SIP: sip: user_BOoperatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 190.1.15.2 

m=audio 11324 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=omr- codecs : 2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 telephone-event 

a=omr-m-att :2 rtpmap:97 AMR-WB/16000/1 

a=omr-m-att : 2 fmtp:97 mode-change-capability=2 ; max-red=220 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=visited-realm:3 Yb.operatorY.net IN IP4 190.1.15.2 11324 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



6. INVITE request (IBCF-3 to IBCF-4) - see example in table A.4.2-6. 

The IBCF-3 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-2, and bypass is allowed according to operator X and operator Y 
agreements, and the previous realm instance match the outgoing realm so that no local MR is required. 

The IBCF-3: 

uses the connection address and port information for the media line in the SDP offer with the connection- 
address and port information from the selected instance 2 as incoming connection address and incoming port 
information for the media line; 

reconstruct the associated codec information for the media line in the received SDP offer from the selected 
instance 2 as described in subclause 5.3, i.e. using the SDP a-lines, b-lines, transport format and list of media 
formats of the media line in the received SDP offer; 

- deletes the visited-realm instance 3; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; 
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computes a checksum value for the media line as described in subclause 5.6.3 and adds the omr-m-cksum 
and omr-s-cksum attributes for the media line. The omr-s-cksum attribute is set to "0" since there are no 
session hne attributes to compute the checksum on; and 

- selects an IBCF, IBCF-4, in the realm "Xa.operatorX.net" and forwards the SDP offer according to 3GPP TS 
24.229 [4] to IBCF-4. 

Table A.4.2-6: SIP INVITE request (IBCF-3 to IBCF-4) 



INVITE SIP: sipiUE- BaoperatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm: 1 Xa . operatorX . net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=omr- codecs : 2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 telephone-event 

a=omr-m-att :2 rtpmap:97 AMR-WB/16000/1 

a=omr-m-att : 2 fmtp:97 mode-change-capability=2 ; max-red=220 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=omr-m-cksum: ( . . ) 

a=omr-m-cksum: 



7. INVITE request (IBCF-4 to P-CSCF B) - see example in table A.4.2-7. 

The IBCF-4 uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-1, and the previous realm instance match the outgoing realm so that 
no local MR is required. 

The IBCF-4: 

uses the connection address and port information from the SDP c-hne in the received SDP offer in the SDP 
offer as incoming connection address and incoming port information in subsequent steps; 

use the port information from the SDP m-line in the received SDP offer as incoming port in subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 
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uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; and 

uses the incoming port information as port information in the SDP m-Hne of the modified SDP offer; and 

forwards the INVITE request with the unmodified SDP offer to the P-CSCF-B, in the realm 
"X.operatorX.net" according to 3GPP TS 24.229 [4]. 

Table A.4.2-7: SIP INVITE request (IBCF-4 to P-CSCF B) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s= 

c=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=omr-codecs :2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 telephone-event 

a=omr-m-att :2 rtpmap:97 AMR-WB/16000/1 

a=omr-m-att : 2 fmtp:97 mode-change-capability=2 ; max-red=220 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=omr-m-cksum: ( . . ) 

a=omr-m-cksum: 



8. INVITE request (P-CSCF to UE- B) - see example in table A.4.2-8. 

The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR is required to match the incoming realm to the outgoing realm. 

uses the connection-address from the SDP c-line as incoming connection-address; 

uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; 

according to the local policy, deletes all OMR attributes from the SDP offer; and 

- forwards the INVITE request with the unmodified SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 
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Table A.4.2-8: SIP INVITE request (P-CSCF-B to UE-B) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 



9. 183 (Session Progress) response (UE-B to P-CSCF-B) - see example in table A.4.2-9. 

The UE accepts the /VMR codec and sends a 183 (Session Progress) response with an SDP offer indicating that 
resources are not yet available to P-CSCF-B according to 3GPP TS 24.229 [4]. 

Table A.4.2-9: 183 (Session Progress) response (UE-B to P-CSCF-B) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

C=IN IP4 192 .0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 240 

b=AS:30 

b=RS:0 

b=RR:2000 



10. 183 (Session Progress) response (P-CSCF-B to IBCF-4) - see example in table A.4.2-9 

The P-CSCF-B uses the procedures in subclauses 6.2.7 and 6.2.9 since the connection address is valid and no 
primary local MR was allocated. 

The P-CSCF-B: 

does not modify the SDP answer and forwards the 183 (Session Progress) response with the SDP answer to 
lBCF-4 according to 3GPP TS 24.229 [4]. 

11. 183 (Session Progress) response (IBCF-4 to IBCF-3) - see example in table A.4.2-11 
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The IBCF-4 uses procedures in subclauses 6.2.7 and 6.2.9 since a valid connection address was received in the 
SDP answer and no MR was allocated when sending the SDP answer. 

The IBCF-4: 

copies into the media line of the SDP answer the visited-realm instance 2 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer; 

replaces the connection address information in the SDP answer with the unspecified address of IPv4, i.e. 
"0.0.0.0"; and 

forwards the 183 (Session Progress) response with the modified SDP answer according to 3GPP TS 24.229 
[4]. 

Table A.4.2-11 : 183 (Session Progress) response (IBCF-4 to IBCF-3) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

c=IN IP4 0.0.0.0 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.4 16511 



12-13. 183 (Session Progress) response (IBCF-3 to IBCF-2 via intermediate IMS CN subsystem entities) - see 
example in table A.4.2-11 

The IBCF-3 uses procedures in subclauses 6.2.5 and 6.2.9 since an unspecified connection address and a visited- 
realm was received. 

The IBCF-3 forwards the 183 (Session Progress) response with the unmodified SDP answer to the intermediate 
IM CN subsustem entities according to 3GPP TS 24.229 [4]. 

The intermediate IM CN subsystem entities forwards without modification the 183 (Session Progress) response 
to the IBCF-2 according to 3GPP TS 24.229 [4]. 

14. 183 (Session Progress) response (IBCF-2 to IBCF-1) - see example in table A.4.2-14 

The IBCF-2 uses the procedures in subclauses 6.2.5 and 6.2.9 since the SDP answer contained an unspecified 
connection address and a realm instance matching one in the received SDP offer and the local MR allocated in 

step 4 can be bypassed. 

The IBCF-2: 

replaces the connection address and port information for the media line in the SDP answer with the 
connection address and port information from the visited-realm instance 2 in the received SDP answer. 

The IBCF-2 retains the primary local MR allocated for realm matching in step 4, until it is no longer potentially 
needed for this and any other forked dialog. 
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The IBCF-2 forwards the 183 (Session Progress) response with SDP answer to IBCF-1 according to 3GPP TS 

24.229 [4]. 

Table A.4.2-14: 183 (Session Progress) response (IBCF-2 to IBCF-1) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

C=IN IP4 192 .0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 240 

b=AS:30 

b=RS : 

b=RR:2000 



15. PRACK request (IBCF-1 to IBCF-2) - see example in table A.4.2-15 

The IBCF-1 determines by subclause 6.2.3 that a transcoder MR is needed since the UE-B selected the codec 
added by lBCF-1 in step 7. The lBCF-4 uses subclause 6.1.5, 6.1.6 and 6.1.9 since no IMS-ALG can be 
bypassed and a primary MR is allocated. 

The IBCF-1: 

uses the connection-address from the SDP c-line in the original SDP offer as incoming connection-address in 
subsequent steps; 

uses the port information from the SDP m-line in the original SDP offer as incoming port information in 

subsequent steps; 

use the codec information from the SDP m-line and associated non-OMR attribute lines in the original SDP 
offer as incoming codec information in the subsequent steps; 

allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
connection address and port information and the outgoing signalling path; 

inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information; 

remove all OMR specific attributes from the modified SDP offer; 

replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

inserts the modified codec information (keeps the telephone-event codec, removes the AMR-WB codec and 
adds the AMR codec) into the SDP m-line and associated attribute lines of the modified SDP offer; 

adds to the modified SDP offer a visited-realm instance 2 for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer ; 

provides to the MR the modified codec information; 
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computes checksum values as described in subclause 5.6.3 adds the "omr-s-cksum" and "omr-m-cksum" 
attributes for the media line; and 

- forwards the PRACK request with the SDP answer to IBCF-2 according to 3GPP TS 24.229 [4]. 
Table A.4.2-15: PRACK request (IBCF-1 to IBCF-2) 



PRACK SIP: sip: UE-BOoperatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:2000 

c=IN IP4 192.0.2.5 

m=audio 18435 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

a=visited-realm:2 Xa . operatorX . net IN IP4 192.0.2.5 18435 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: ( . . ) 



16-17. PRACK request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) - see example in 
table A.4.2-16 

The IBCF-2 uses the procedures in subclauses 6.1.5, 6.1.6 and 6.1.9 since no previous MRs can be bupassed and 
a local MR is needed for realm matching. 

The IBCF-2: 

uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address 
in subsequent steps; 

uses the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; and 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps. 

inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information;- 

replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

add to the modified SDP offer a visited-realm instance 3 for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer; 

computes checksum values as described in subclause 5.6.3 and replace or add the "omr-s-cksum" and "omr- 
m-cksum" attributes for the media line; and 

forwards the PRACK request with the modified SDP offer to the intermediate IM CN subsystem entities 
according to 3GPP TS 24.229 [4]. 
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The intermediate IM CN subsystem entities forwards the PRACK request without modifying the SDP offer to 
the IBCF-3 according to 3GPP TS 24.229 [4]. 

Table A.4.2-16: PRACK request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) 



PRACK SIP: sip: UE-B@operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:2000 

C=IN IP4 190.1.15.2 

m=audio 11324 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 18435 

a=visited-realm:3 Yb.operatorY.net IN IP4 190.1.15.2 11324 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: { . . ) 



18. PRACK request (IBCF-3 to IBCF-4) - see example in table A.4.2-18 

The IBCF-3 uses procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since previous MR can be bypassed and no 
local MR is needed. 

The IBCF: 

uses the connection address and port information from the selected instance 2 for the media line in the 
received SDP offer as incoming connection address and incoming port information for the media line in the 
subsequent steps; 

reconstructs the associated codec information for the media line in the received SDP offer from the selected 
instance 2 as described in subclause 5.3, and use that codec information as incoming codec information in the 
subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer, 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; and 

uses the incoming port information as determined in previous steps as port information in the SDP m-line of 
the modified SDP offer; 

computes checksum values as described in subclause 5.6.3 and replaces the "omr-s-cksum" and "omr-m- 
cksum" attributes for the media line; and 

- forwards the PRACK request with the modified the SDP offer to IBCF-2 according to 3GPP TS 24.229 [4]. 
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Table A.4.2-18: PRACK request (IBCF-3 to IBCF-4) 



PRACK SIP: sip: UE-B@operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:20 

C=IN IP4 192 .0.2.5 

m=audio 18435 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 240 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 18435 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: { . . ) 



19. PRACK request (IBCF-4 to P-CSCF-B) - see example in table A.4.2-18 

The IBCF-4 uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since allocation of a local MR is not needed 
and no previous MR can be by passed. 

The IBCF-4: 

uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address 
in subsequent steps; 

uses the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as determined in previous steps as port information in the SDP m-line of 
the modified SDP offer; and 

- forwards the PRACK request with the unmodified the SDP offer to P-CSCF-B according to 3GPP TS 24.229 
[4]. 



20. PRACK request (P-CSCF-B to UE- B) - see example in table A.4.2-20. 

The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR is required to match the incoming realm to the outgoing realm. 

uses the connection-address from the SDP c-line as incoming connection-address; 

uses the port information from the SDP m-line as incoming port information; 
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uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; 

inserts the incoming codec information into the SDP m-Hne and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; 

according to the local policy, deletes the visited-realm "visited-realm:l Xa.operatorX.net IN IP4 192.0.2.5 
18435", the omr-s-cksum:(..) and the "omr-m-cksum=(..)" from the SDP offer ; and 

- forwards the UPDATE request with the modified SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 
Table A.4.2-20: SIP PRACK request (P-CSCF-B to UE-B) 



UPDATE SIP: sip : UE-B@operatorX . net ; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

C=IN IP4 192.0.2.5 

m=audio 18435 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 



21. 200 (OK) response (UE-B to P-CSCF-B) - see example in table A.4.2-21. 

The UE accepts the /VMR codec (again) and sends a 200 (OK) response to the PRACK request with an SDP 
answer still indicating that resources are not yet available to P-CSCF-B according to 3GPP TS 24.229 [4]. 
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Table A.4.2-21 : 200 (OK) response to PRACK request (UE-B to P-CSCF-B) 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

b=AS:30 

b=RS : 

b=RR:20 

C=IN IP4 192 .0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 



22. 200 (OK) response (P-CSCF-B to IBCF-4) - see example in table A.4.2-21. 

The P-CSCF-B uses the procedures in subclauses 6.2.7 and 6.2.9 since no local MR was allocated the connection 
address is valid and no visited-realm instance was received in the SDP answer. 

The P-CSCF-B: 

does not modify the SDP answer and forwards the 200 (OK) response with the SDP answer to IBCF-4 
according to 3GPP TS 24.229 [4]. 

23. 200 (OK) response (IBCF-4 to IBCF-3) - see example in table A.4.2-21. 

The IBCF-4 uses the procedures in subclauses 6.2.7 and 6.2.9 since no local MR was allocated allocated and a 
valid connection address was received in the SDP answer. 

The IBCF-4 forwards the 200 (OK) response to the PRACK request with the unmodified SDP answer 
according to 3GPP TS 24.229 [4]. 

24-25. 200 (OK) response (IBCF-3 to IBCF-2 via intermediate IM CN subsystem entities) - see example in 
table A.4.2-24. 

The IBCF-3 uses procedures in subclauses 6.2.7 and 6.2.9 since no local MR was allocated allocated and an 
unspecified connection address and no visited-realm instance was received in the SDP answer. 

The IBCF-3: 

copies into the media line of the SDP answer the visited-realm instance 2 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer; 

replaces the connection address information in the SDP answer with the unspecified address of the IPv4, i.e. 
"0.0.0.0"; and 

forwards the 200 (OK) response to the PRACK request with the modified SDP answer to the intermediate IM 
CN subsystem entities according to 3GPP TS 24.229 [4]. 

The intermediate IM CN subsystem entities forwards the 200 (OK) response to the PRACK request to the IBCF- 
2 according to 3GPP TS 24.229 [4] without modifying the SDP offer. 
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Table A.4.2-24: 200 (OK) response to PRACK request (IBCF-3 to IBCF-2 via intermediate IIUI CN 

subsystem entities) 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

b=AS:30 

b=RS : 

b=RR:2000 

c=IN IP4 0.0.0.0 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

a=visited-realm:2 Xa.operatorX.net 192.0.2.4 16511 



26. 200 (OK) response (IBCF-2 to IBCF-1) - see example in table A.4.2-26. 

The IBCF-2 uses the procedures in subclauses 6.2.5 and 6.2.9 since an unspecified connection address and a visited- 
realm instance was received. 

The IBCF-2: 

replaces the connection address and port information for the media line in the SDP answer with the 
connection address and port information from the visited-realm instance 2 in the received SDP answer; 

forwards the 200 (OK) response to the PRACK request with the modified SDP answer to IBCF-1 according 
to 3GPP TS 24.229 [4]; and 

keeps the allocated MR until it is no longer potentially needed for this and any other forked dialog. 
Table A.4.2-26: 200 (OK) response to PRACK request (IBCF-2 to IBCF-1) 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

b=AS:30 

b=RS : 

b=RR:2000 

c=IN IP4 192 .0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 
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27. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) - see example in table A.4.2-27. 

The IBCF-1 continues from the point when the 183 (Session Progress) response to the INVITE request was 
received in step 14 and uses the procedures in subclauses 6.2.8 and 6.2.9 since the IBCF-4 retains the MR 
allocated in 4step 14. 

The IBCF-1: 

updates the remote connection address and port information for the outgoing termination on the selected MR 
context with the connection address and port information for the media line in the received SDP answer; 

modifies the SDP answer to include the codecs selected for the incoming termination of the selected local 
MR; 

replaces the connection address and port information for the media line in the SDP answer with the local 
connection address and port information for the incoming termination on the selected MR; 

removes the visited-realm instance; and 

forwards 183 (Session Progress) response with the modified SDP answer to P-CSCF-A according to 3GPP 
TS 24.229 [4]. 

Table A.4.2-27 183 (Session Progress) response (IBCF-1 to P-CSCF-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.3 

s = - 

b=AS:30 

b=RS:0 

b=RR:2000 

c=IN IP4 192 .0.2.2 

m=audio 23563 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

a=maxptime : 24 



28. 183 (Session Progress) response (P-CSCF-A to UE-A) - see example in table A.4.2-27 

The P-CSCF-A forwards the 183 (Session Progress) with the SDP answer to the UE-A according to 3GPP TS 

24.229 [4]. 

29-30. PRACK request (UE-A to IBCF-1 via P-CSCF-A). 

The UE-A acknowledge the receiption of the SDP offer and the 183 (Session Progress) response by means of a 
PRACK request. 

31-32. 200 (OK) response to the PRACK request (IBCF-1 to UE-A via P-CSCF-A). 

The IBCF-1 acknowledges the reception of the PRACK request by means of a 200 (OK) response. 
33. UPDATE request (UE-A to P-CSCF-A) - see example in table A.4.2-33. 

When the UE-A has got resources reserved the UE-A sends an UPDATE request. 
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The SDP offer in the UPDATE the request is the same as the SDP offer in the INVITE request in the step 1 with 
the only exception that "a=curr:qos local none" is now changed to "a=curr:qos local sendrecv". 

Table A.4.2.-33: UPDATE request (UE-A to P-CSCF-A) 



UPDATE SIP: sip: UE-A@operatorX.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:2000 

C=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR-WB/16000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 24 



34-40. UPDATE request (P-CSCF-A to UE-B via IBCF-1, IBCF-2, intermediate IMS CN subsystem entities 
IBCF-3, IBCF-4 and P-CSCF-B). 

34) The P-CSCF-A prepares the SDP offer in the same way as in step 2. 

35) The IBCF-1 prepares the SDP offer in the same way as in step 15 with the exception that the MR allocated in 
15 is reused. 

36) The IBCF-2 prepares the SDP offer in the same way as in step 16. 

37) Intermediate IMS CN subsystem entities do not manipulate the SDP offer. 

38) The IBCF-3 prepares the SDP offer in the same way as in step 18. 

39) The IBCF-4 prepares the SDP offer in the same way as in step 19. 

40) The P-CSCF-B prepares the SDP offer in the same way as in step 20. 

41. 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B) - see example in table A.4.2-41. 

The UE-B acknowledges the reception of the UPDATE request by means of a 200 (OK) response containing an 
SDP answer. 
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Table A.4.2-41 : 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B). 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

C=IN IP4 192.0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR/8000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



42-48. 200 (OK) response to the UPDATE request (P-CSCF-B to UE-A via IBCF-4, IBCF-3, intermediate 
IMS CN subsystem entities, IBCF-2 and IBCF-1). 

42) The P-CSCF-B prepares the SDP answer in the same way as in step 22. 

43) The IBCF-4 prepares the SDP answer in the same way as in step 23. 

44) The IBCF-3 prepares the SDP answer in the same way as in step 24. 

45) Intermediate IMS CN subsystem entities do not manipulate the SDP answer. 

46) The IBCF-2 prepares the SDP answer in the same way as in step 26. 

47) The IBCF-1 prepares the SDP answer in the same way as in step 27. 

48) The P-CSCF-A performs the same actions as in step 28. 

49-56. 180 (Ringing) response (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, intermediate IMS CN 
subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

No OMR specific action is required. 

57-64. 200 (OK) response to the INVITE request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediated IMS CN subsystem, IBCF-2, IBCF-1 and P-CSCF-A). 

The User B accepts the call and the UE-B sends a 200 (OK) response to the INVITE request. The response 
contains no SDP. 

The IBCF-2 releases the MR not used in the call. 

65-72. ACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediated IMS CN subsystem, 
IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-B acknowledges the receiption of the 200 (OK) response by means of a 200 (OK) response. 



A.5 IMS-ALG bypasses an allocated transcoding MR 
A. 5.1 General 

This subclause provides an example of a call where the UE initiating a call offers the AMR codec. An IMS-ALG, 
IBCF-1 in figure A.2.1, adds the AMR-WB codec to the initial SDP offer and reserves an MR resource. 
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The terminating UE selects the AMR codec and the IMS-ALG needs to deallocate the MR and update the terminating 
UE with the IP addresses of the UE-A in a realm instance to allow bypassing of the IMS-ALG itself. 

Figure A.5.1-1 shows the realm and IP structure used in this example. 



IBCF-2 




Home IMS network Y: 
Realm Yb.operatorY.net 



Intermediate IMS 
CN subsystem entities 

z 



PCRF 
^iPDNGW!"" 




Visited network X: 
Realm Xa.operatorX.net 



PCRF 
■►JPDNGW^*- 



UE-B 



192.0.2.4 



-►: Controll signalling path 



■ — •► : Media path after OMR 



Figure A.5.1-1 : IP realm and IP structure. 



A. 5. 2 Message flow 



The user A at UE-A and the user B at UE-B roams into a visited network X and both users belongs to the same operator 
Y. 

Preconditions: 

Both users A and B are registered to the Home IMS network Y via the visited operator X network; 

the visited operator X and the operator of user A and B IMS home network Y have an agreement to allow media 
to be bypassed using OMR; 

both users A and B are connected to realm Xa of the visited operator network X; 

the AMR codec is allowed and accepted by all involved entities. However, the local policy of operator X is that 
the AMR-WB codec shall always be included in the initial SDP offers from the operator X network; and 

no B2BUA manipulating SDP is connected in the intermediate IM CN subsystem. 

Figure A.5.2-1 shows the message flow for the scenario. 
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WB, 
c=192.0.2.5, 
~visited-realm:1 Xa* 
192.0.2.1, 
visited-fealm:2 Xa 
192.0.2.5 
AMR] 

10. 183 

«- [AMR, — 
c=1 92.0.2.4] 



11. PRACK 

[AMR, 

- c=1 92.0.2.1, * 

visited-fealm:1 Xa 

192.0.2.1] 

14. 200 OK 
(PRACK) _ 

[AMR, 
c=1 92.0.2.4] 



39. UPDATE 
[AMR and AMR- 
WB , 
c=192.0.2.1, 
visited.reaim:1 Xa 
192.0.2.1] 



42. 200 OK 

,_ (UPDATE) _ 

[AMR, 
c=1 92.0.2.4] 



58.200OK_ 
(INVITE) 



-71.ACK- 



UE-B 



8. INVITE 
JAMR and AMR- 
WB, • 
c=1 92.0.2.5] 



9.183 

- [AMR, - 
c=1 92.0.2.4] 



12. PRACK 

- [AMR, H 
c=1 92.0.2.1] 



13. 200 OK 

_ (PRACK) _ 

[AMR, 

c=1 92.0.2.4] 



40. UPDATE 

.[AMRandAMR-, 

WB 

c=192.0.2.1] 



41. 200 OK 
l_(UPDATE)_ 

[AMR, 
c=1 92.0.2.4] 



57. 200 0K_ 
(INVITE) 



-72. ACK- 



Figure A.5.2-1 : Message flow for transcoder with resource reservation, codec not selected. 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 

The steps of the flow are as follows: 

1. INVITE request (UE-A to P-CSCF-A) - see example in table A.5.2-1. 

The UE-A sends a SIP INVITE request according to 3GPP TS 24.229 [4]. The INVITE request includes an SDP 
offer proposing the use of the AMR codec and inband DTMF. 
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Table A.5.2-1 : SIP INVITE request (UE-A to P-CSCF-A) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:20 

C=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 



2. INVITE request (P-CSCF-A to IBCF-1) - see example in table A,5.2-l. 

The P-CSCF-A uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no MR could be bypassed and no 
MR is allocated. 

The P-CSCF-A: 

uses the connection-address from the SDP c-line as incoming connection-address; 

uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer, and 

use the incoming port information as port information in the SDP m-line of the modified SDP offer. 

The P-CSCF-A then selects an IBCF, IBCF-1, in the realm "Xa.operatorX.net" and forwards the INVITE request 
with the SDP offer to the IBCF-1 according to 3GPP TS 24.229 [4]. 

3. INVITE request (IBCF-1 to IBCF-2) - see example in table A.5.2-3 

The IBCF-1 uses the procedures in 6.1.5, 6.1.6 and 6.1.9 since IBCF-1 determines according to local policy that 
a transcodng MR is needed and that there is no previous MR to bypass. 

The IBCF-1: 

uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address 
in subsequent steps; 

uses the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps; 

allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
connection address and port information and the outgoing signalling path; 
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inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information; 

constructs a visited-realm instance 1 ; 

replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

adds a AMR-WB codec changes to incoming codec information, according to local policy, taking into 
account the procedures in clause 5.4, and insert the changed codec information into the SDP m-line and 
associated attribute lines of the modified SDP offer; 

provides to the MR the modified codec information; 

adds to the modified SDP offer a visited-realm instance 2 for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer, including the incoming codec 
information encoded according to clause 5.2; 

computes checksum values as described in subclause 5.6.3 and adds the "omr-s-cksum" and "omr-m-cksum" 
attributes for the media line. The "omr-s-cksum" is set to "0" since there is no session line attributes to 
compute the checksum on; and 

selects an IBCF, IBCF-2, in the realm "Xa.operatorX.net" and forwards the INVITE request with the 
modified SDP offer to the IBCF-2 according to 3GPP TS 24.229 [4]. 
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Table A.5.2-3: SIP INVITE request (IBCF-1 to IBCF-2) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192 .0.2.5 

m=audio 62111 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=rtpmap:98 AMR-WB/16000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 240 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111 

a=omr- codecs : 2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 

a=omr-m-att : 2 telephone -event 

a=omr-m-att :2 rtpmap:97 AMR/8000/1 

a=omr-m-att : 2 fmtp:97 

a=omr-m-att : 2 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



4-5. INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) - see example in 
table A.5.2-4 

The IMS-ALG uses the procedures in subclauses 6.1.5, 6.1.6 and 6.1.9 since no MR can be bypassed and a local 
MR is needed for realm matching. 

The IBCF-2: 

uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

uses the port information from the SDP m-line as incoming port information in subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information in the subsequent steps. 

allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
connection address and port information and the outgoing signalling path; 

inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

provides to the MR the incoming codec information; 
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replaces the connection address and port information for the media hne in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

adds to the modified SDP offer a visited-realm instance 3 for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer; and 

computes checksum values as described in subclause 5.6.3 and adds the "omr-s-cksum" and "omr-m-cksum" 
attributes for the media line. The "omr-s-cksum" is set to "0" since there is no session line attributes to 
compute the checksum on. 

None of the intermediate IMS CN subsystem entities manipulated with the SDP offer but the identity of 
user B ©operator Y.net in the Request-URI is change to the contact address, i.e. UE-B@operatorX.net. 

The intermediate IMS CN subsystem entities select an IBCF, IBCF-3, in the realm "Ya.operatorY.net" and 
forward the INVITE request with the SDP offer to the IBCF-3 according to 3GPP TS 24.229 [4]. 

Table A.5.2-4: SIP INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S15 IN IP4 192.0.2.1 

s= 

c=IN IP4 190 .1.15.2 

m=audio 11324 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=rtpmap:98 AMR-WB/16000/1 

a=fmtp:98 mode - change - capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 24 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111 

a=omr- codecs : 2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 

a=omr-m-att : 2 telephone-event 

a=omr-m-att :2 rtpmap:97 AMR/8000/1 

a=omr-m-att : 2 fmtp:97 

a=omr-m-att : 2 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=visited-realm: 3 Ya.operatorY.net IN IP4 190.1.15.2 11324 

a=omr-m-cksum: ( . . ) 

a=omr-s-cksum: 



6. INVITE request (IBCF-3 to IBCF-4) - see example in table A.5.2-6 

The IBCF-3 uses procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since previous MRs can be bypassed and no 
local MR is needed for realm matching. 

The IBCF-3: 
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uses the connection address and port information from the selected instance 2 for the media Hne in the SDP 
offer as incoming connection address and incoming port information for the media line in the subsequent 
steps. The instance 2 is selected since it contains more codecs than the visited-realm instance 1 ; 

reconstructs the associated codec information for the media line in the SDP offer from the selected instance 2 
according to subclause 5.3 and uses that codec information as incoming codec information in the subsequent 
steps; 

deletes visited-realm instance 3; 

insert the incoming codec information into the SDP m-line and associated attribute lines of the modified SDP 
offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as determined in previous steps as port information in the SDP m-line of 
the modified SDP offer; 

computes checksum values as described in subclause 5.6.3 and adds the "omr-s-cksum" and "omr-m-cksum" 
attributes for the media line. The "omr-s-cksum" is set to "0" since there is no session line attributes to 
compute the checksum on; and 

selects an IBCF, IBCF-4, in the realm "Xa.operatorX.net" and forwards the INVITE request with the SDP 
offer according to 3GPP TS 24.229 [4] to IBCF-4. 
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Table A.5.2-6: SIP INVITE request (IBCF-3 to IBCF-4) 



INVITE SIP: UE-BOoperator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192 .0.2.5 

m=audio 62111 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=rtpmap:98 AMR-WB/16000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 240 

b=AS:30 

b=RS : 

b=RR:2000 

a=visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111 

a=omr- codecs : audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 

a=omr-m-att : 2 telephone -event 

a=omr-m-att :2 rtpmap:97 AMR/8000/1 

a=omr-m-att : 2 fmtp:97 

a=omr-m-att : 2 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



7. INVITE request (IBCF-4 to P-CSCF B) - see example in table A.5.2-7. 

The IBCF-4 uses procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since the visited-realm with the highest instance 
number is connected to the same realm as the IBCF-4 and contains codecs according to the local policy. Using 
the visited-realm instance 1 would reduce the number of available codecs. No MR for realm matching is needed. 

The IBCF-4: 

uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address 
in subsequent steps; 

uses the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; and 
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use the incoming port information as determined in previous steps as port information in the SDP m-Hne of 
the modified SDP offer; and 

- forwards the INVITE request with the unmodified SDP offer to the P-CSCF-B according to 3GPP TS 24.229 
[4]. 

Table A.5.2-7: SIP INVITE request (IBCF-4 to P-CSCF B) 



INVITE SIP: UE-BOoperator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192.0.2.3 

m=audio 62111 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220; octet-align=l 

a=rtpmap:98 AMR-WB/16000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 240 

b=AS:30 

b=RS:0 

b=RR:2000 

a=visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111 

a=omr-codecs :2 audio RTP/AVP 96 97 

a=omr-m-att : 2 rtpmap:96 

a=omr-m-att : 2 telephone-event 

a=omr-m-att :2 rtpmap:97 AMR/8000/1 

a=omr-m-att : 2 fmtp:97 

a=omr-m-att : 2 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=omr-m-att : 2 curr:qos local none 

a=omr-m-att : 2 curr:qos remote none 

a=omr-m-att : 2 des:qos mandatory local sendrecv 

a=omr-m-att : 2 des:qos none remote sendrecv 

a=omr-m-att : 2 ptime:20 

a=omr-m-att : 2 maxptime:240 

a=omr-s-bw:2 AS: 30 

a=omr-s-bw:2 RS : 

a=omr-s-bw:2 RR:2000 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



8. INVITE request (P-CSCF to UE- B) - see example in table A.5.2-8. 

The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR for realm matching is needed. 

The P-CSCF-B: 

uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address 
in subsequent steps; 

uses the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 
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uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

use the incoming port information as determined in previous steps as port information in the SDP m-Hne of 
the modified SDP offer; 

deletes all OMR attributes from the SDP offer according to the local policy; and 

- forwards the INVITE request with the modified SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 

Table A.5.2-8: SIP INVITE request (P-CSCF to UE-B) 



INVITE SIP: UE-B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

c=IN IP4 192 .0.2.5 

m=audio 62111 RTP/AVP 96 97 98 

b=AS:30 

b=RS : 

b=RR:20 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=rtpmap:98 AMR-WB/16000/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 240 



9. 183 (Session Progress) response (UE-B to P-CSCF-B) - see example in table A.5.2-9. 

The UE accepts the AMR codec and sends a 183 (Session Progress) response to P-CSCF-B with an SDP offer 
indicating that resources are not yet available according to 3GPP TS 24.229 [4]. 

Table A.5.2-9: 183 (Session Progress) response (UE-B to P-CSCF-B) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

C=IN IP4 192.0.2.4 

m=audio 16511 RTP/AVP 96 97 

b=AS:30 

b=RS : 

b=RR:2000 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone-event 

a=rtpmap: 97 AMR/8000/1 

a=fmtp: 97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 
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10. 183 (Session Progress) response (P-CSCF-B to IBCF-4) - see example in table A.5.2-9 

The P-CSCF-B uses the procedures in subclauses 6.2.7 and 6.2.9 since the connection address is vaHd and no 
primary local MR was allocated when the SDP offer was sent. 

The P-CSCF-B forwards the 183 (Session Progress) response with the unmodified SDP answer to IBCF-4 
according to 3GPP TS 24.229 [4]. 

11. PRACK request (IBCF-4 to P-CSCF-B) - see example in table A.5.2-11. 

The IBCF-4 uses the procedure in subclause 6.2.2 to determine that the transcoder allocated by IBCF-1 is not 
needed any longer and that an UPDATE request can be sent to update the IP address according to visited-realm 
instance 1. 

The IBCF-4 uses the procedures in 6.1.4, 6.1.7 and 6.1.9 since the previous MR at IBCF-1 can be bypassed and 
no local MR is needed for realm matching. 

The IBCF-4: 

uses the connection address and port information from the selected visited-realm instance 1 for the media line 
in the received SDP offer (receivied in the initial INVITE request in step 6) as incoming connection address 
and incoming port information for the media line in the subsequent steps; 

reconstructs the associated codec information for the media line in the received SDP offer from the selected 
instance 1 as described in subclause 5.3, and use the AMR codec and associated attribute lines as incoming 
codec information in the subsequent steps; 

deletes every OMR attribute for the media line with instance-number value 2 and 3; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; 

computes checksum values as described in subclause 5.6.3 and replaces or add the "omr-s-cksum" and "omr- 
m-cksum" attributes for the media line; and 

- sends the PRACK request with the modified SDP offer to P-CSCF-B according to 3GPP TS 24.229 [4]. 
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Table A.5.2-11 : SIP PRACK request (IBCF-4 to P-CSCF-B) 



UPDATE SIP: UE_BOoperator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:20 

c= IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=qos local none 

a=curr: qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=ptime : 20 

a=maxptime : 240 

a=visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.1 49170 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: { . . ) 



12. PRACK request (P-CSCF-B to UE-B) - see example in table A.5.2-12. 

The P-CSCF-B uses the procedure in 6.1.5, 6.1.7 and 6.1.9 since there are no MR to bypass and since no local 
MR is allocated for realm matching. 

The P-CSCF-B: 

uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address 
in subsequent steps; 

uses the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; 

deletes all OMR related attributes from the SDP offer according to local policy; and 

- forwards the UPDATE request and the modified SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 
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Table A.5.2-12: SIP UPDATE request (P-CSCF-B to UE-B) 



PRACK SIP: UE_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

b=AS:30 

b=RS : 

b=RR:20 

c= IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=rtpmap:96 telephone-event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=qos local none 

a=curr: qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=ptime : 20 

a=maxptime : 240 



13. 200 (OK) response (UE-B to P-CSCF-B) - see the SDP example in table A.5.2-9. 

The UE accepts the /VMR codec and sends a 200 (OK) response to the UPDATE request to P-CSCF-B with an 
SDP offer indicating that resources are not yet available according to 3GPP TS 24.229 [4]. 

14. 200 (OK) response (P-CSCF-B to IBCF-4) - see the SDP example in table A.5.2-9. 

The P-CSCF-B uses the procedures in subclauses 6.2.7 and 6.2.9 since the connection address is valid and no 
primary local MR was allocated when the SDP offer was sent. 

The P-CSCF-B forwards the 200 (OK) response to the UPDATE request with the unmodified SDP answer to 
IBCF-4 according to 3GPP TS 24.229 [4]. 

15. 183 (Session Progress) response (IBCF-4 - to IBCF-3) - see example in table A.5.2-15. 

The IBCF-4 continues from the point in step 10 where the 183 (Session Progress) response was received with an 
SDP answer corresponding to the visited -realm 1 and no transcoding by IBCF-1 was required. 

The IBCF-4 uses the procedures in subclause 6.2.7 and 6.2.9 since a valid connection address was received in 
the 200 (OK) response to the UPDATE request and no MR was allocated when the SDP offer was sent. 

The IBCF-4: 

copies into the media line of the SDP answer the visited-realm instance 1 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer; 

replaces the connection address information in the SDP answer with the unspecified address of IPv4, 
"0.0.0.0"; and 

sends the 183 (Session Progress) response with the modified SDP answer to the IBCF-3 according to 3GPP 
TS 24.229 [4]. 
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Table A.5.2-15: 183 (Session Progress) response (IBCF-4 - to IBCF-3) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

b=AS:30 

b=RS : 

b=RR:2000 

C=IN IP4 0.0.0.0 

m=audio 16511 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 

a=visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.4 16511 



16-17. 183 (Session Progress) response (IBCF-3 to IBCF-2 via intermeadiate IM CN subsystem entities) - see 
example in table A.5.2-16. 

The IBCF-3 uses the procedures in subclauses 6.2.5 and 6.2.9 since the SDP answer contains an unspecified 
connection address and a visited-realm instance and the allocated MR is not needed. 

The IBCF-3 forwards the 183 (Session Progress) response with the unmodified SDP answer to the intermeadiate 
IM CN subsystem entities according to 3GPP TS 24.229 [4]. 

The intermeadiate IM CN subsystem entities forwards the 183 (Session Progress) response with the unmodified 
SDP answer to the IBCF-2 according to 3GPP TS 24.229 [4] 

18. 183 (Session Progress) response (IBCF-2 to IBCF-1) - see example in table A.5.2-16. 

The IBCF-2 uses procedures in subclauses 6.2.5 and 6.2.9 since an unspecified connection address and a visited- 
realm instance was received and the allocated MR is not needed. 

IBCF-2: 

forwards the 183 (Session Progress) response with the unmodified SDP answer to IBCF-1 according to 3GPP 
TS 24.229 [4]; and 

keeps the allocated MR until it is no longer potentially needed for this and any other forked dialog. 

19. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) - see example in table A.5.2-19. 

The IBCF-1 uses the procedures in subclauses 6.2.5 and 6.2.9 since an unspecified connection address and a 
visited-realm instance was received and the MR allocated for trancoding is not needed. 

replaces the connection address and port information for the media line in the SDP answer with the 
connection address and port information from the visited-realm instance 1 in the received SDP answer; 

forwards the 183 (Session Progress) response with the modified SDP answer to P-CSCF-A according to 
3GPPTS 24.229 [4]; and 

keeps the MR allocated for trancoding until it is no longer potentially needed for this and any other forked 
dialog. 
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Table A.5.2-19: 183 (Session Progress) response (IBCF-1 to P-CSCF-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

b=AS:30 

b=RS : 

b=RR:20 

C=IN IP4 192 .0.2.4 

m=audio 16511 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a = r tpmap :96 telephone- event 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-change-capability=2 ; max-red=220 ; octet-align=l 

a=ptime : 20 

a=maxptime : 24 



20. 183 (Session Progress) response (P-CSCF-A to UE-A) - see example in table A.5.2-23. 

The P-CSCF-A uses procedures in subclause 6.2.7 and 6.2.9 since a valid connection address is received and no 
MR was allocated when the SDP offer was sent. 

P-CSCF-A: 

delete the visited-realm instance according to local policy; and 

forwards the 183 (Session Progress) response with the unmodified SDP answer to the UE-B according to 
3GPPTS 24.229 [4]. 

21-74. Remaining SIP message for establishing the call 

The rest of the steps follow the same principles as described in subclause A. 2. 2 steps 17 - 65 with the following 
clarifications: 

The IBCF-1, following the recommendation in subclause 8.2, continues to add the AMR-WB to any SDP 
offer but using the proactive transcoding without resource reservation principle instead. 



A.6 Loopback routeing via an intermediate network 
A.6.1 General 

This subclause provides an example on how OMR is used to find an optimal media path when loopback routeing is used 
and how to preserve signalling paths and media paths compatible with the existing CS charging model. 

The example does not focus on the OMR algorithm as such instead the focus is on the selection and configuration of IP 
realm names. The example only describes the message flow on the originating side. 

Figure A.6. 1-1 shows the IP realm and IP configuration used in this example. 
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UE-A 




IBCF-5 



TrGW 



-►: Contrail signalling path 
►: Media path after OMR 



Figure A.6.1-1 : IP realm and IP address configurations. 



A. 6. 2 Message flow 



The user A at UE-A is roaming into a visited network V. The user A is a subscriber of operator H. 

Preconditions in this example: 

The user A is registered to the Home IMS network H via the visited operator V network and the IC network X; 
The IC network does not store any registration information. 

P-CSCF-A and S-CSCF supports loopback routeing; 

- IBCF-1, IBCF-2, IBCF-3, IBCF-4, IBCF-5, IC-1 and IC-2 supports OMR and all networks supports loopback 
routeing; 

IBCF-1, IBCF-4 and IBCF-5 are instances in the same physical IBCF in the visited network V; 

IC-1 and IC-2 are instances in the same physical IC hub; 

IBCF-2 and IBCF-3 are instances in the same physical IBCF in the home network H; and 

no B2BUA manipulating SDP is connected in the home operator H network. 

Figure A. 6. 2-1 shows the message flow for the scenario. 
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Visited network V 



IC network X 



Home IMS network H (of user A) 



IC network X 



Visited network V 



I I I I I 

Realm: Va.operatotV.net (Va in the '^^^''^^^■|J^"^*j}-^°^^^^ Ha.operatorA.net (Ha in the Realm Xa.IC.net ( Local realm Xa1, Realm: Va.operatotV.net (Va In the 

^ flowbelow) i-,*Xa1,Xa2andXa4intheflow-^,^ flow below) -^l ^ Xa2 and Xa4 in the flow below) ^;* fL below) "" 



UE-A 



P-CSCF-A 



IBCF-1 



IC1 

Xa2 



2. INVITE 

FC=TRFURI, 
— PAN!, 
[SDP:AlylR 
0=192.0.2.1] 



19. 183 
-[SDP:AlylR,— 

c=1 92.0.2.4] 



Resource 
authorization 



20. 183 

-[SDP:AlylR, — 
0=192.0.2.4] 



3. INVITE 
FC=TRF URI, 
PAN!, 
[SDP: AIWIR 
0=178.15.1.1, ■ 
visited-realm:1 Va 

192.0.2.1, 

^fisited-realm:2Xa1 

178.15.1.1] 



18. 183 
[SDP:AlylR, 
0=0.0.0.0, 
isited-realm:1 Va 
192.0.2.4] 



IBCF-2 



4. INVITE 

FC-TRFURI, 

PAN!, 

[SDP:AlylR 

0=179.14.1.1, 

visited-realm:1 Va » 

192.0.2.1, 
visited-realm:2Xa1 

178.15.1.1, 

visited-realm:3Xa2 

179.14.1.1] 



17. 183 

[SDP:AlylR, 

I 0=0.0.0.0, 

visited-realm:1 Va 

192.0.2.4] 



S-CSCF/ 
BGCF 



IBCF-3 



5. INVITE 

FC=TRF URI, 

PAN!, 

[SDP: AIWIR 

0=190.1.15.1, 

visited-realm:1 Va 

192.0.2.1, ►■ 
visitEd-realm:2Xa1 

178.15.1.1, 
visitEd-realm:3Xa2 

179.14.1.1, 

visited-realm:4Ha 

190.1.15.1] 



16. 183 

[SDP:AlylR, 
I 0=0.0.0.0, - 
visited-realm:1 Va 

192.0.2.4] 



6. INVITE 
FC=Loopbaol<, 

PAN!, 
R:TRF address 

[SDP: AIWIR 

0=190.1.15.1, 

.visitEd-realm:1 Va , 

192.0.2.1, 
visited-realm:2Xa1 

178.15.1.1, 

visited-realm:3Xa2 

179.14.1.1, 

visitEd-realm:4 

190.1.15.1] 



15. 183 
[SDP:AlylR, 
0=0.0.0.0, 
sitEd-realm:1 Va 
192.0.2.4] 



IC2 

Xa2 



7. INVITE 
FC=Loopbaol<, 

PAN!, 
R:TRF address, 

[SDP: AIWIR 

0=179.14.1.3, 

visited-realm:1 Va 

192.0.2.1, J 
visited-realm:2Xa1 

178.15.1.1, 
visited-realm:3Xa2 

179.14.1.1, 
visited-realm:4 Ha 

190.1.15.1, 

visited-realm:5Xa4 

179.14.1.3] 



14. 183 
[SDP:AlylR, 
I 0=0.0.0.0, 
visited-realm:1 Va 

192.0.2.4] 



IBCF-4 



TRF 



IBCF-5 



8. INVITE 






FC=Loopbacl<, 






PAN!, 






R:TRF address. 


9. INVITE 




[SDP: AHflR 
0=179.14.1.1, ^ 


FC-Loopbacl<, 

PAN!, 




visitEd-realm:1 Va 

192.0.2.1, 

sited-realm:2Xa1 

178.15.1.1, 


R:TRF address ^^ 
[SDP:AHflR 
0=192.0.2.1, 
visited-realm:1 Va 


10. INVITE 
[SDP: AHflR 
0=192.0.2.1, 


sited-realm:3Xa2 
179.14.1.1] 


192.0.2.1] 


192.0.2.1] 



13. 183 12. 183 11. 183 

[SDP:Af^R, [SDP:AtVlR, [SDP: AIWIR, 

I 0=0.0.0.0, — •* c-192.0.2.4, — •^— 0=192.0.2.4, - 

visitEd-realm:1 Va visted-realm:1 Va visted-realm:1 Va 

192.0.2.4] 192.0.2.4] 192.0.2.4] 



21 . PRACK and 200 OK PRACK without an SDP offer 



Resource 
reservation 



22. UPDATE and 200 OK to UPDATE with the same SDP offer as in the INVITE but preconditions for UE-A are now fulfilled, preconditions for remote UE is still not fulfilled. 



32. UPDATE 

* [SDP:AlylR, — 
0=192.0.2.4] 



33. 200 OK 

_ FC=TRF URI _| 
[SDP:AlylR, 
0=192.0.2.1] 



31. UPDATE 

* [SDP:AlylR, - 
0=192.0.2.4] 



34. 200 OK 

_ FC=TRFURI _| 
[SDP:AlylR, 
0=192.0.2.1] 



: 



30. UPDATE 

[SDP:AlylR, 

0=179.14.1.4, 

visited-realm:1 Va 

I 192.0.2.4, 

visited-realm:2Xa1, 

178.15.1.4, 

visited-realm:3Xa2 

179.14.1.4] 



35. 200 OK 

FC=TRF URI 

[SDP:AlylR, I 

0=0.0.0.0, 

visitEd-realm: 1 Va 

192.0.2.1] 



29. UPDATE 

[SDP:AtVlR, 

0=179.14.1.2, 

visited-realm:1 Va 

192.0.2.4, 
visited-realm:2Xa1, 
I 178.15.1.4, 
visited-realm:3Xa2 

179.14.1.4, 
visited-realm:4 Ha 

190.1.15.2, 

visited-realm:5Xa4 

179.14.1.2] 

36. 200 OK 
FC=TRF URI 
[SDP:AlylR, ^ 
0=0.0.0.0, 
visited-realm: 1 Va 
192.0.2.1] 



28. UPDATE 

[SDP:AiyiR, 

0=190.1.15.2, 

visited-realm :1 Va 

192.0.2.4, 
■*^fisited-reaim:2Xa1,- 

178.15.1.4, 
isitEd-reaim:3Xa2 

179.14.1.4, 
'isited-reaim:4 Ha 

190.1.15.2] 



37. 200 OK 

FC=TRF URI 
[SDP:AlylR, ^ 
0=0.0.0.0, 
visited-reaim: 1 Va 
192.0.2.1] 



27. UPDATE 

[SDP:AlylR, 

0=190.1.15.2, 

visitEd-reaim:1 Va 

192.0.2.4, 

•visited-reaim:2Xa1,- 

178.15.1.4, 
visited-reaim:3Xa2 

179.14.1.4, 

visited-reaim:4 Ha 

190.1.15.2] 



38. 200 OK 

FC=Loopback 

[SDP:AIWR, p 

0=0.0.0.0, 

visited-reaim: 1 Va 

192.0.2.1] 



26. UPDATE 

[SDP:AlylR, 

0=179.14.1.4, 

visited-reaim:1 Va 

I 192.0.2.4, 

visitEd-reaim:2Xa1, 

178.15.1.4, 

visited-reaim:3Xa2 

179.14.1.4] 



39. 200 OK 

FG-Loopbaok 

[SDP:AiyiR, J 

0=0.0.0.0, 

visited-reaim: 1 Va 

192.0.2.1] 



43. 200 OK INVITE (without SDP) and ACK 



25. UPDATE 

[SDP:AlylR, 

0=178.15.1.4, 

I visited-reaim :1 Va - 

192.0.2.4, 

visited-reaim:2Xa1, 

178.15.1.4] 



40. 200 OK 

FC=Loopbaok 

[SDP:AiyiR, ^ 

0=0.0.0.0, 

visited-reaim: 1 Va 

192.0.2.1] 



24. UPDATE 

[SDP:AiyiR, 

* 0=192.0.2.4, - 

visited-reaim:1 Va 

192.0.2.4] 



41. 200 OK 

FC=Loopbaok 

[SDP:AiyiR, ^ 

0=192.0.2.1, 

visited-reaim: 1 Va 

192.0.2.1] 



23. UPDATE 

[SDP:AtVlR, 

- 0=192.0.2.4, - 

visited-reaim:1 Va 

192.0.2.4] 



42. 200 OK 

[SDP:AlylR, 

- 0=192.0.2.1, H 

visited-reaim: 1 Va 

192.0.2.1] 



Figure A.6.2-1 : Message flow for loopback routeing via an IC network. 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow. 
The steps of the flow are as follows: 

1. INVITE request (UE-A to P-CSCF-A) - see example in table A.6.2-1. 

The user A at UE-A initiates a call. The UE-A sends an initial INVITE request to the P-CSCF-A according to 

3GPPTS 24.229 [4]. 
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Table A.6.2-1 : INVITE request (UE-A to P-CSCF-A) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip ipcscf 1 .visitedV.net; lr> 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos optional remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



2. INVITE request (P-CSCF-A to IBCF-1) - see example in table A.6.2-2. 

When the P-CSCF-A receives the initial INVITE request and, since the user A is a roaming user, the P-CSCF- 
adds the Feature-Caps header field with the g.3gpp.trf with the address to the TRF; and 

The P-CSCF-A selects an IBCF (IBCF-1) to be the exit IBCF towards the home IMS network H of the user A 
and sends the INVITE request according to 3GPP TS 24.229 [4] to IBCF-1. 

Table A.6.2-1 : INVITE request (P-CSCF-A to IBCF-1) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : scscf 1 . operatorH . net ; lr> 

Feature -Caps : +g. 3gpp . trf ="<sip : trf 1 . visitedV.net >" 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=2 34 15 IDOFCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



3. INVITE request (IBCF-1 to IC-1) - see example in table A.6.2-3. 

When the IBCF-1 receives the initial INVITE request containing the "H-g.3gpp.trf" header field parameter in a 
Feature-Caps header field, the IBCF-1 updates the SDP as follows: 

the media parameters received from the TrGW are included in the SDP; 
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the IP address, port number and the IP realm Va.operatorV.net of the UE-A is included as the visited-realm 1 
instance; 

the IP address, port number of the TrGW and the local IP realm Xal.operatorX.net are included as the 
visited-realm 2 instance. To avoid unwanted optimal media paths being created the local IP realm 
Xal.operatorX.net is selected as this is a local IP realm only known by the IBCF-1, IBCF-4 and IBCF-5. 

The IBCF-1 selects to route the INVITE request via an IC network and sends the INVITE request according to 
3GPP TS 24.229 [4] to the IC-1. 

Table A.6.2-3: INVITE request (IBCF-1 to IC-1) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : scscf 1 . operatorH . net ; lr> 

Feature -Caps : +g. 3gpp . trf ="<sip : trf 1 . visitedv.net >" 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=2 34 15 IDOFCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 178.15.1.1 

m=audio 62111 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.1 62111 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



4. INVITE request (IC-1 to IBCF-2) - see example in table A.6.2-4. 

When the IC-1 receives the initial INVITE request and since the IC-1 according to local policy allows itself to be 
bypassed by media then the IC-1 updates the SDP as follows: 

the media parameters of the IC-1 are included in the SDP; and 

the IP address, port number of the IC-1 and the local IP realm Xa2.operatorX.net are included as the visited- 
realm 3 instance. To avoid unwanted optimal media paths being created the local IP realm Xa2.operatorX.net 
is selected as this is a local IP realm only known by the IC-1 and IC-2. 

The IC-1 selects an entry IBCF of the home IMS network H and sends the INVITE request according to 
3GPP TS 24.229 [4] to the IBCF-2. 
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Table A.6.2-4: INVITE request (IC-1 to IBCF-2) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : scscf 1 .operatorH.net; lr> 
Feature -Caps : +g. 3gpp. trf ="<sip : trf 1 . visitedV.net >" 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=234151D0FCEll 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ;orig- 
ioi= " Va . operatorV . net " 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 179.14.1.1 

m=audio 52211 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.1 62111 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211 

a=omr-m-cksum: ( . . ) 

a=omr-s-cksum: 



5. INVITE request (IBCF-2 to S-CSCF) - see example in table A.6.2-5. 

When the IBCF-2 receives the initial INVITE request containing the "+g.3gpp.trf" header field parameter in a 
Feature-Caps header field, the IBCF-2 updates the SDP as follows: 

the media parameters of the TrGW are included in the SDP; and 

the IP address, port number of the TrGW and the IP realm Ha.operatorH.net are included as the visited-realm 
4 instance. 

The IBCF-2 sends the INVITE request according to 3GPP TS 24.229 [4] to the S-CSCF. 
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Table A.6.2-5: INVITE request (IBCF-2 to S-CSCF) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : scscf 1 .operatorH.net; lr> 
Feature -Caps : +g. 3gpp. trf ="<sip : trf 1 . visitedV.net >" 

P-Access -Network- Info :3GPP-UTRAN-TDD;utran- cell- id- 3gpp=234151D0FCEll 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ;orig- 
ioi= " Va . operatorV . net " 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 190.1.15.1 

m=audio 16789 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.1 62111 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211 

a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.1 16789 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



6. INVITE request (S-CSCF to IBCF-3) - see example in table A.6.2-6. 

When the S-CSCF receives the initial INVITE request the S-CSCF decides according to local policy that 
loopback routeing shall be used. 

The S-CSCF: 

includes the TRF URI included in the g.3gpp.trf in the Route header field; 

includes in a Feature-Caps header field the feature tag +g.3gpp. loopback to indicate that loopback routeing is 
ongoing; and 

replaces the received orig-ioi parameter value in the P-Charging- Vector header field with the value 
Ha.operatorH.net identifying the home IMS network H. 

NOTE: Number normalization and ENUM translation is deferred to the visited network. 

The S-CSCF/BGCF selects an entry IBCF and sends the INVITE request according to 3GPP TS 24.229 [4] to 
the IBCF-3. 
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Table A.6.2-6: INVITE request (S-CSCF to IBCF-3) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : trf 1 .visitedV.net; lr> 

Feature-Caps : +g . 3gpp . loopback 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=234151D0FCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 190.1.15.1 

m=audio 16789 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.1 62111 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211 

a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.1 16789 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



7. INVITE request (IBCF-3 to IC-2) - see example in table A.6.2-7. 

When the IBCF-3 receives the initial INVITE request containing the "+g.3gpp. loopback" header field parameter 
in a Feature-Caps header field, the IBCF-3 updates the SDP as follows: 

the media parameters of the TrGW are included in the SDP; and 

the IP address, port number of the TrGW and the local IP realm Xa4.operatorX.net are included as the 
visited-realm 5 instance. To avoid unwanted optimal media paths being created the local IP realm 
Xa4.operatorX.net is selected as this is a local IP realm only known by the IBCF-2 and IBCF-3. 

The IBCF-3 selects to route the INVITE request via an IC network and sends the INVITE request according to 
3GPP TS 24.229 [4] to the IC-2. 



ETSI 



3GPP TS 29.079 version 1 1 .3.0 Release 1 1 83 ETSI TS 1 29 079 V1 1 .3.0 (201 3-04) 

Table A.6.2-7: INVITE request (IBCF-3 to IC-2) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : trf 1 .visitedV.net; lr> 

Feature-Caps : +g . 3gpp . loopback 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=234151D0FCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 179.14.1.3 

m=audio 34500 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.1 62111 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211 

a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.1 16789 

a=visited-realm: 5 Xa4.operatorX.net IN IP4 179.14.1.3 34500 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



8. INVITE request (IC-2 to IBCF-4) - see example in table A.6.2-8. 

When the IC-2 receives the initial INVITE request the IC-2 detects that an optimal media path avoiding media to 
be sent through the home IMS network H is possible. The IC-2 updates the SDP as follows: 

the IP address and port number included by IC-1 in visited -realm instance 3 are included in the SDP; and 

the visited-realm instances 4 and 5 are removed so that the media path is no longer passing the home IMS 
network H. 

The IC-2 selects an entry IBCF in the visited network and sends the INVITE request according to 
3GPP TS 24.229 [4] to the IBCF-4. 
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Table A.6.2-8: INVITE request (IC-2 to IBCF-4) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : trf 1 .visitedV.net; lr> 

Feature-Caps : +g . 3gpp . loopback 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=234151D0FCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 179.14.1.1 

m=audio 52211 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.1 62111 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



9. INVITE request (IBCF-4 to TRF) - see example in table A.6.2-9. 

When the IBCF-4 receives the initial INVITE request containing the "+g. 3 gpp. loopback" header field parameter 
in a Feature-Caps header field, the IBCF-4 searches for a possible optimal media path and detects that an optimal 
media path within the visited network is possible. The IBCF-4 updates the SDP as follows: 

the IP address and port numbers in the visited-realm instance 1 is included in the SDP; and 

the visited-realm instances 2 and 3 are removed so that the media path is no longer passing the IC network. 

The IBCF-4 sends the INVITE request according to 3GPP TS 24.229 [4] to the TRF. 
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Table A.6.2-9: INVITE request (IBCF-4 to TRF) 



INVITE SIP: tel:+4687197378; SIP/2.0 

Route : <sip : trf 1 .visitedV.net; lr> 

Feature-Caps : +g . 3gpp . loopback 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=234151D0FCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



10. INVITE request (TRF to IBCF-5) - see example in table A.6.2-10. 

When the TRF receives the initial INVITE request the TRF: 

performs number normalization and ENUM translation and updates the Request-URI if necessary; and 

inserts an orig-ioi parameter value in the P-Charging- Vector header field with the value Va.operatorV.net 
identifying the visited network. 

The TRF selects an exit IBCF and sends the INVITE request according to 3GPP TS 24.229 [4] to the IBCF-5. 
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Table A.6.2-10: INVITE request (TRF to IBCF-5) 



INVITE SIP: <sip: +46107197378(BoperatorY;user=phone> SIP/2.0 

Feature -Caps : +g. 3gpp . omr="di sable -omr" 

P-Access -Network- Info:3GPP-UTRAN-TDD;utran- cell- id- 3gpp=2 34 15 IDOFCEll 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig- 
ioi= " Va . operatorV . net " 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

c=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.1 49170 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



11. 183 (Session Progress) response (IBCF-5 to TRF) - see example in table A.6.2-11. 

When the IBCF-5 receives the initial INVITE request the IBCF-5 sends the INVITE request towards the 
terminating network. The INVITE request may or may not include OMR specific parameters based on the IBCF- 
5 local policy. 

When the IBCF-5 receives an SDP answer in a 183 (Session Progress) response from the terminating network 
the IBCF-5: 

includes its own IP address and port number received from the TrGW in the SDP. 

The IBCF sends the 183 (Session Progress) response according to 3GPP TS 24.229 [4] to the TRF. 

Table A.6.2-11 : 183 (Session Progress) response (IBCF-5 to TRF) 



SIP/2.0 183 Session Progress 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;term- 
ioi= "y . operatorY . net " 

Other SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 192.0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 
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12. 183 (Session Progress) response (TRF to IBCF-4) - see example in table A.6.2-12. 

When the TRF receives the 183 (Session Progress) response the TRF stores the received term-ioi; and 
The TRF sends the 183 (Session Progress) response according to 3GPP TS 24.229 [4] to the IBCF-4. 

Table A.6.2-12: 183 (Session Progress) response (TRF to IBCF-4) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 192 .0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 



13-15. 183 (Session Progress) response (IBCF-4 to S-CSCF via IC-2 and IBCF-3) - see example in table A.6.2- 
13. 

When the IBCF-4 receives the 183 (Session Progress) response the IBCF-4 updates the SDP as follows: 

- The c=IN IP4 192.0.2.4 is replaced with an invaUd IPv4 address, i.e. c=IN IP4 0.0.0.0, since the IP realm on 
visited network side and the IC network side are not the same hence the received IP address is not valid on 
the IC side. 

The IBCF-4 sends the 183 (Session Progress) response according to 3GPP TS 24.229 [4] towards the S-CSCF 
via the IC-2 and IBCF-3. Neither the IC-2 nor the IBCF-3 updates the SDP. 

Table A.6.2-13: 183 (Session Progress) response (IBCF-4 to S-CSCF via IC-2 and IBCF-3) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 0.0.0.0 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 



16-18. 183 (Session Progress) response (S-CSCF to IBCF-1 via IBCF-2 and IC-1) - see example in table A.6.2- 
16. 
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The S-CCSCF sends the 183 (Session Progress) response according to 3GPPTS 24.229 [4] to the IBCF-1. 
Neither the IBCF-2 nor IC-1 updates the SDP. 

Table A.6.2-16: 183 (Session Progress) response (S-CSCF to IBCF-1 via IBCF-2 and IC-1) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

C=IN IP4 0.0.0.0 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 



19. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) - see example in table A.6.2-19. 

When the IBCF-1 receives the 183 (Session Progress) response the IBCF-1 updates the SDP. 

The IBCF-1: 

replaces the received invalid IPv4 address with the IP address received in the visited-realm instance 1 ; and 

removes all OMR specific attributes since the SDP offer from P-CSCF-A did not contain any OMR specific 
attributes. 

The IBCF-1 sends the 183 (Session Progress) response according to 3GPP TS 24.229 [4] to the P-CSCF-A. 
Table A.6.2-19: 183 (Session Progress) response (IBCF-1 to P-CSCF-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 192.0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 



20. 183 (Session Progress) response (P-CSCF-A to UE-A) - see example in table A.6.2-20. 

When the P-CSCF-A receives the 183 (Session Progress) response the P-CSCF authorizes the resources; 
The P-CSCF-A sends the 183 (Session Progress) response according to 3GPP TS 24.229 [4] to the UE-A. 
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Table A.6.2-20: 183 (Session Progress) response (P-CSCF-A to the UE-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

c=IN IP4 192.0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 20 



21. PRACK requests and SIP 200 (OK) response to the SIP PRACK request 

The PRACK is sent without any SDP offer/SDP answer between the UE-A and IBCF-5 according to 
3GPPTS 24.229 [4]. 

22. UPDATE request and SIP 200 (OK) response to the SIP UPDATE request 

The UPDATE request and the response to the 200 (OK) response to the UPDATE request is sent with the same 
SDP offer and SDP answer as in the initial SIP INVITE request and the 183 (Session Progress) response but now 
indicating that resources are reserved at UE-A. The SDP updates are the same as in steps 1 - 20. 

23-24. UPDATE request (IBCF-5 to IBCF-4 via TRF) - see example in table A.6.2-23. 

When the IBCF-5 receives an UPDATE request on the terminating side the IBCF-5 updates the SDP as follows: 

the IP address and port number of the own TrGW is included in the SDP; and 

a visited-realm instance 1 is added with the IP address and port number of the own TrGW and the IP realm 
Va.operatorV.net. 

The IBCF-5 sends the UDATE request according to 3GPP TS 24.229 [4] to the IBCF-5 via TRF. 

The TRF does not update the SDP. 
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Table A.6.2-23: UPDATE request (IBCF-5 to IBCF-4 via TRF) 



UPDATE SIP: sipiUE -AOoperatorH.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 192.0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 20 

visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



25. UPDATE request (IBCF-4 to IC-2) - see example in table A.6.2-25. 

When the IBCF-4 receives the UPDATE request the IBCF-4 updates the SDP as follows: 

the IP address and port number of the own TrGW is included in the SDP; 

a visited-realm instance 2 is added with the IP address and port number of the own TrGW and the local IP 
realm Xal.operatorX.net. The local IP realm Xal.operatorX.net is only known by IBCF-2, IBCF-4 and 
IBCF-5. 

The IBCF-4 sends the UDATE request according to 3GPP TS 24.229 [4] to the IC-2. 
Table A.6.2-25: UPDATE request (IBCF-4 to IC-2) 



UPDATE SIP: sip : UE-AOoperatorH . net ; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 192.0.2.4 

t = 

m=audio 62987 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.4 62987 

a=omr-m-cksum: ( . . ) 

a=omr-s-cksum: 



26. UPDATE request (IC-2 to IBCF-3) - see example in table A.6.2-26. 

When the IC-2 receives the UPDATE request the IC-2 updates the SDP as follows: 
the IP address and port number of the IC-2 is included in the SDP; and 
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a visited-realm instance 3 is added with the IP address and port number of the IC-2 and the local IP realm 
Xa2.operatorX.net. The local IP realm Xa2.operatorX.net is only known by IC-1 and IC-2. 

The IC-2 sends the UDATE request according to 3GPP TS 24.229 [4] to the IBCF-3. 
Table A.6.2-26: UPDATE request (IC-2 to IBCF-3) 



UPDATE SIP: sip: UE-A@operatorH.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 179.14.1.4 

t = 

m=audio 23987 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 IN IP4 Va.operatorV.net 192.0.2.4 16511 

a=visited-realm:2 IN IP4 Xal.operatorX.net 178.15.1.4 62987 

a=visited-realm:3 IN IP4 Xa2.operatorX.net 179.14.1.4 23987 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



27-28. UPDATE request (IBCF-3 to IBCF-2 via S-CSCF) - see example in table A.6.2-27. 

When the IBCF-3 receives the UPDATE request the IBCF-3 updates the SDP as follows: 

the IP address and port number of the own TrGW is included in the SDP; and 

a visited-realm instance 4 is added with the IP address and port number of the own TrGW and the IP realm 
Ha. operatorH. net. 

The IBCF-3 sends the UDATE request according to 3GPP TS 24.229 [4] to the IBCF-2 via the S-CSCF. 

The S-CSCF does not update the SDP. 
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Table A.6.2-27: UPDATE request (IBCF-3 to IBCF-2 via S-CSCF) 



UPDATE SIP: sipiUE -AOoperatorH.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 190.1.15.2 

t = 

m=audio 16543 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.4 62987 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.4 23987 

a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.2 16543 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



29. UPDATE request (IBCF-2 to IC-1) - see example in table A.6.2-29. 

When the IBCF-2 receives the UPDATE request the IBCF-2 updates the SDP as follows: 

the IP address and port number of the own TrGW is included in the SDP; 

a visited-realm instance 5 is added with the IP address and port number of the own TrGW and the local IP 
realm Xa4.operatorX.net. The local IP realm Xa4.operatorX.net is only known by IBCF-3 and IBCF-2. 

The IBCF-2 sends the UDATE request according to 3GPP TS 24.229 [4] to the IC-1. 
Table A.6.2-29: UPDATE request (IBCF-2 to IC-1) 



UPDATE SIP: sip : UE-A@operatorH . net ; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 179.14.1.2 

t = 

m=audio 36543 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.4 62987 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.4 23987 

a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.2 16543 

a=visited-realm:5 Xa4.operatorX.net IN IP4 179.14.1.2 36543 

a=omr-m-cksum: ( . . ) 

a=omr-s-cksum: 
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30. UPDATE request (IC-1 to IBCF-1) - see example in table A.6.2-30. 

When the IC-1 receives the UPDATE request the IC-2 detects that an optimal media path avoiding media to be 
sent through the home IMS network H is possible. The lC-1 updates the SDP as follows: 

the IP address and port number included by lC-2 in visited-realm instance 3 are included in the SDP; and 

the visited-realm instances 4 and 5 are removed so that the media path is no longer passing the home IMS 
network H. 

The IC-1 sends the UPDATE request according to 3GPP TS 24.229 [4] to the IBCF-1. 
Table A.6.2-29: UPDATE request (IC-1 to IBCF-1) 



UPDATE SIP: sip: UE-AOoperatorH.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 179.14.1.4 

t = 

m=audio 23987 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 20 

a=visited-realm: 1 Va.operatorV.net IN IP4 192.0.2.4 16511 

a=visited-realm:2 Xal.operatorX.net IN IP4 178.15.1.4 62987 

a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.4 23987 

a=omr-m-cksum: { . . ) 

a=omr-s-cksum: 



31-32. UPDATE request (IBCF-2 to UE-A) - see example in table A.6.2-31. 

When the IBCF-1 receives the UPDATE request the IBCF-1 detects that an optimal media path within the 
visited network is possible. The IBCF-1 updates the SDP as follows: 

the IP address and port numbers in the visited-realm instance 1 is included in the SDP; and 

since the IBCF-1 did not receive any OMR attributes in the initial SDP offer, all OMR specific attributes are 
removed. 

The IBCF-1 sends the UPDATE request according to 3GPP TS 24.229 [4] to the UE-A via P-CSCF-A. The P- 
CSCF-A does not update the SDP. 
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Table A.6.2-31 : UPDATE request (IBCF-2 to UE-A) 



UPDATE SIP: sipiUE -AOoperatorH.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

c=IN IP4 192.0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 20 



33-34. 200 (OK) response (UE-A to IBCF-1 via P-CSCF-A) - see example in A.6.2-33. 

The UE-A sends the 200 (OK) response according to 3GPP TS 24.229 [4] to the IBCF-1 via the P-CSCF-A. The 
P-CSCF-A does not update the SDP. 

Table A.6.2-34: 200 (OK) response to the UPDATE request (UE-A to IBCF-1 via P-CSCF-A). 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 



35-40. 200 (OK) response (IBCF-1 to IBCF-4 via IC-1, roCF-2, S-CSCF, IBCF-3 and IC-2) - see example in 
table A.6.2-35. 

When the IBCF-1 receives the 200 (OK) response to the UPDATE request the IBCF-1 updates the SDP as 
follows: 

adds an visited-realm instance 1 with the IP address and the port number received from the P-CSCF-A (i.e. 
the UE-A IP address and the port number) and the IP realm Va.operatorV.net; and 

modifies the IP address in the SDP to be an invalid IPv4 address, i.e. 0.0.0.0, since the IP realms on each side 
of the IBCF-1 is different. 

The lBCF-1 sends the 200 (OK) response to the UPDATE request to the IBCF-4 via IC-1, IBCF-2, S-CSCF, 
IBCF-3 and IC-2. Neither one of IC-1, IBCF-2, S-CSCF, IBCF-3 nor IC-2 updates the SDP. 
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Table A.6.2-35: 200 (OK) response to the UPDATE request (IBCF-1 to IBCF-4 via IC-1, IBCF-2, S-CSCF, 

IBCF-3 and IC-2). 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

c=IN IP4 0.0.0.0 

m=audio 49170 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

visited-realm:l Va IN IP4 192.0.2.1 49170 



41-42. 200 (OK) response (IBCF-4 to IBCF-5 via TRF). 

When the IBCF-4 receives the 200 (OK) response to the UPDATE request the IBCF-1 updates the SDP. 

The IBCF-4 replaces the received invalid IPv4 address with the IP address received in the visited-realm instance 
1. 

The IBCF-4 sends the 200 (OK) response to the UPDATE request according to 3GPP TS 24.229 [4] to the 
IBCF-5 via the TRF. The TRF does not modify the SDP. 

Table A.6.2-35: 200 (OK) response to the UPDATE request (IBCF-4 to IBCF-5 via TRF). 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

visited-realm: 1 Va IN IP4 192.0.2.1 49170 



43. 200 (OK) response to INVITE request and the SIP ACK request 

The 200 (OK) response to the initial INVITE request is sent according to 3GPP TS 24.229 [4] between the 
IBCF-5 and UE-A as specified in 3GPP TS 24.229 [4]. 

The ACK request is sent according to 3GPP TS 24.229 [4] between the UE-A and IBCF-5 as specified in 
3GPPTS 24.229 [4]. 
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